Issues Animating Player Collision Mesh (LOS?)

#21 Hey guys, we ran into another issue. While the hitboxes (that have materials and are visible) look perfectly correct in-game but the LoS check doesn't seem to work. Even though the shapes are in the right locations and this is confirmed, they appear to be... invisibly scaled in the Z-axis.

It's a bit hard to describe but the important bit is that while the hitboxes appear to do everything they should, the LoS check hits mesh that isn't there.

Thanks!

#22 github.com/Azaezel/modelExperiments testing as I have time. Couple simplified rigs up to play with and verify. Think the second one pertains to that z you were referring to. I can say that the scaling experiment had enough side-effects with child-objects that I'd actively recommend against using scale bones.

#23 I apologize if I'm uninformed, but aren't those experiment models using Collision, rather than Hitbox? We've been using Hitbox code.

Thanks

#24 mountpoints childed to bones to check the resultant relative positioning once imported. (though yes, the swappable collision stuff is inherent to my grabbing testable models out of my stash of programmer 'art')

edit: point being from what I can tell based on simple-to-check rigs, the z value is being added twice as a stock blender 'feature'. Once from the parent bone, a second time from the origin of the object which has a bone as it's parent, and really really weirdly if you don't have the last keyframe set as where you're at in the animation when exporting.

#25 Right, right, we actually waded through that the other day. I really should have explained that a lot better than I did. Sorry. But, um, our issue is different now. Now, Torque recognizes our hitbox meshes as being in the correct place.

However, it's never that easy. The model we're currently using is scaled by .135 on all axes in torque, and since it is already animated, we can't scale it down in blender without breaking everything horribly. Basically, the issue is that while everything is scaled just fine by Torque, including the visible mesh of the hitboxes, the "functional mesh" of the hitboxes are not. ie everything looks correct in torque (the hitboxes are visible) but if you aim above or below the actual hitbox mesh the los still collides with.. something.

My programmer suspects it's something to do with the scaling code of the hitbox add-on? I don't really understand much of it, but I can relay what the current situation is to the best of my ability.

Thank you again for all of your help thus far.

#26 OK, there's some data I can chew on. Will go digging.

#27

Quote:The model we're currently using is scaled by .135 on all axes in torque, and since it is already animated, we can't scale it down in blender without breaking everything horribly.

verifying: You using something similar to what we are this end, like

%obj.setScale(%scale);

or a different methodology? (*Shouldn't* make a difference but the little details sometimes do.)

#28 I'm not sure if it's what you're asking but the way that we scaled in torque was just using the object editor, so changing the 'Scale' field on the player object.

I hope that helps while I wait for a reply from my programmer.

#29 well, going down the list, in case there's an obvious blind spot on my part, I think we can likely rule out void Player::onScaleChanged(), since that just sets the mScaledBox to mObjBox (not used for the castray)
as far as:
bool Player::castRay(const Point3F &start, const Point3F &end, RayInfo* info), that one references mObjBox direct...

that'll lead us to bool TSShapeInstance::castRayEA(const Point3F & a, const Point3F & b, RayInfo * rayInfo, S32 dl, S32 HBIndex) and
bool TSShapeInstance::MeshObjectInstance::castRayEA(S32 objectDetail, const Point3F & start, const Point3F & end, RayInfo * rayInfo, TSMaterialList* materials)

for comparing with the stock methods for anything overlooked...

the MeshObjectInstance one just tosses out the !forceHidden && visible > 0.01f ) flags from a normal one...

TSShapeInstance::castRayEA vs TSShapeInstance::castRay doesn't show anything in particular amiss there aside from some redundancy checking...

animation specific adds would be:
github.com/Azaezel/Torque3D/commit/7a1c33d6d194ae078d745f4ec3d59af82d391184#diff... if it's only going wonky once animated...

doesn't seem too terribly different than
bool ShapeBase::castRay(const Point3F &start, const Point3F &end, RayInfo* info)
for comparison there.

#30 Hi Azaezel,

I'm the other guy working on this with Mike. The "scaling" we do is actually on importing a fresh dae into the engine (so I wouldn't expect Player::onScaleChanged() to be involved?).

singleton TSShapeConstructor(SurvivorDae2)
{
   baseShape = "./survivor.dae";
   ignoreNodeScale = "1"; // <- needed to fix animations.
   loadLights = "0";
   unit = "0.135"; // <- setting for importing
};

It seems like (based on our last and current problem) Torque importing isn't properly considering children of bones when exported from Blender (I can't vouch for 3DS Max or any other as we don't have licences for those...).

I started looking at some of the Torque import code myself to see if I could narrow down on what was going on (that was a bad idea!). I looked through most of the classes I believe have to do with importing. I stepped through a couple of functions that reference scale and they returned (seemingly) correct values.

Those scales I checked were only when a node named "Hitbox#" were passed through for processing. I'm guessing, that something up the line is doing something wrong, or the rayCast is obtaining data to check that shouldn't be there. I looked briefly through the castRayEA function and didn't find anything the jumped out as wrong (although a lot of this stuff is getting out of my realm of understanding).

I hope some of that helps; I get more lost on this every day. We've always had lots of issues importing models into Torque from Blender (mostly because we don't have a fully trained artist I guess), so I guess the issue could be with how Blender is exporting dae's compared to other programs or us forgetting to check the magic "make it work" button.

#31 Between this one, and the github PR commentary, I'm beginning to suspect something may be up prior to github.com/Azaezel/Torque3D/commit/7a1c33d6d194ae078d745f4ec3d59af82d391184#diff... Where it finds the relevant object. Not generally in my wheelhouse yet, I'm afraid. Perhaps someone more well versed in the TSShapeConstructor code could chime in there.