View Full Version : Interpreting Bone restParams();

08-09-2005, 02:00 PM
(Note: Some of this is copied from a post on another form (SplineCage.com). Forgive the cross-post, but it's been frustratingly hard to find the information I need)

I'm fairly new to working with the Lightwave SDK (version 8.0 if it matters), and have been working on an exporter for our artist to get models and animations into our game engine, which I have been programming along side the exporter. Thus far I've managed to get positional and UV data (both continous and discontinuous maps... THAT was a pain!) exported, along with generating my own normals, and have started on bone/animation exporting.

I'm running into a lot of problems when it comes to interperating the bone information that I am getting back from both boneInfo->restParam() and itemInfo->param() particularly, I am trying to get world positional coordinates for the skeleton in it's bind pose (restParam). querying the itemInfo of the bone for LWIP_W_POSITION returns a wonderfully complete and correct set of positions for the bones (in an animated pose, of course), but when attempting to use the same query on boneInfo->restParam I get nothing but garbage floating point numbers.

Through a lot of experimentation I've dicovered that the only querys that give back a valid result when using restParam are: LWIP_POSITION, LWIP_ROTATION, and LWIP_SCALING, even though the SDK seems to suggest that any query you can pass to itemInfo->param should work. In any case, I now have a lot of "relative" data, and very little idea as to how they relate to eachother. My exact problems are:

1) What order are the rotational values applied in? This is mentioned nowhere in the SDK documentation, and I had to download the open source tools to even get a hint at their order. It appears that the values returned are in the order Y,X,Z and should be applied in that order to get a correct rotation matrix, but I have no way of knowing this for sure since I haven't been able to get correct results out of it, and the SDK docs are silent on the issue.

2) I cannot figure out what exactly the position is supposed to represent. From the description it would seem that it's a simple offset from it's parent in world coordinates, but in practice it seems that you need to apply a series of rotations first in order to get the "real" position. This isn't documented in any way, of course, and I've ended up wasting hours simply trying different combinations of calculations to no avail. So how exactly is this value interperated? Do I rotate it by it's own rotational value, or it's parents? And do those rotations need to be recursivly calculated or are they absolute? (SDK says they're relative, but I've actually gotten "better" results when treating them as absolute rotations) I guess I would need to know how to handle the rotational values first, of course...

I have more questions, but I feel these two need to be worked out first. Thank you for any help that can be given!

-Toji (Tojiart.com (http://www.tojiart.com) )

08-09-2005, 06:21 PM
Okay, the coordinates which those give you are all in parent coordinate spaces, so if your parent is at (1,2,3) and your child is at (4,5,6), this means your child is at (5,7,9) in the world. It is not an offset in world coordinates, but from the parent in the parent's coordinate system. So if your parent is rotated through 90 deg in the Y, and the child is at (0,0,1) then it'll actually be at (1,0,0) in world coordinates.

The pivot of an object can be moved in the scene however, and this is a value offset from the origin in worldspace for the object if it was in it's original position(as if it had come directly from modeler and wasn't parented to anything). For games you shouldn't really have your artists use this function as it adds to the list of transforms you have to do, so make them build everything so their objects' pivot points are at (0,0,0) in modeler, and then position them in layout.

Rotation is done Heading, pitch, bank (which corresponds to Y,X,Z order), and again, the child's rotations are from the parent's coordinate system.

You really need to have a play in LW yourself to see how it all works.

I hope this has helped, I'm not really big on the maths side of it myself, this is how it works as far as I can tell.

The values you get should all be reliable (unless they're from Ik'd systems, as IK is evaluated on top of any keyframes. You can get your artists to use Motion Baker to bake out any IK motion though to keyframes which will be correct)

08-09-2005, 07:34 PM
Awesome! That was EXACTLY what I was looking for! Now I just need to implement that in my calculations ^_^ Thank you VERY much!

Now, for one final question: Why is it that none of that is in the SDK Docs? :rolleyes:

08-10-2005, 03:35 AM
I assume cause they assume you can actually go look in LW and see what's going on. Once you're in there it's all fairly obvious... Would be handier if they pointed this all out in the docs for programmers though :)