Meaning of "jointOrientX" and friends?

Other Standards COLLADA
1

I can’t find a reference to what jointOrient-named rotates/translates actually mean. I have a file that has something like:

<library_visual_scenes>
<visual_scene id=“RootNode” name=“RootNode”>
<node id=“Camera01” name=“Camera01”>
<translate sid=“translate”>0.000000 39.042583 54.017147</translate>
<rotate sid=“jointOrientX”>1 0 0 -90.000000</rotate>
<rotate sid=“rotateZ”>0 0 1 0.000000</rotate>
<rotate sid=“rotateY”>0 1 0 -0.000000</rotate>
<rotate sid=“rotateX”>1 0 0 58.404297</rotate>
<rotate sid=“post-rotationY”>0 1 0 90.000000</rotate>
<instance_camera url="#Camera01-lib"/>
</node>
…

Are the sid’s actually meaningful, or are they simply interpretive/descriptive?

I have a file that I’m using to test out a homegrown viewer app (based on the FCollada code), and I presume that’s doing the right things under the covers. But I just added the ability to have notes with no geometry apply t/r/s onto the modelview stack – and now can’t see the sample object.

Granted, the sample object was a bit odd to begin with, which was why I realized I had to allow matrix application at every node in the tree, regardless of type or physical geometry. But it’s just not working, and then I decided to really look at the data, and found stuff like the above ‘extra’ elements. I should note there are no joints or skinning, this should be (reasonably) simple meshes in a scene, some of which are in a hierarchy, some of which are animated (so possible my animation code is messed up too…).

Thanks for any leads!

-david

2

<rotate sid=“jointOrientX”>1 0 0 -90.000000</rotate>
…
Are the sid’s actually meaningful, or are they simply interpretive/descriptive?
They’re meaningful for finding animation targets and things of that sort, but the sid doesn’t affect the value of the rotation in the <rotate> element there.

So you can’t see the object when you apply <node> transforms but you can see it otherwise? You’re not push/popping the matrix stack for every <node> in the model are you? Does OpenGL report any errors (assuming you’re using OpenGL)? Also you should make sure the transforms on the <node>s are all sensible. Will your viewer load other sample models ok, or do all models have this problem? Can you load your test model in other Collada viewers, like the Feeling Viewer?

3

Ahhhh… Animation targets! I should have caught that. That makes complete sense. Though still not sure why a bone/joint would need a singular separate entry – but I guess I can imagine cases where you have a node that wants to control a bone and has stuff attached to it that is independent of that bone… or something like that.

I finally JUST worked it out. I think it had to do with when/where I was doing the push/pop. I did some refactoring of the code, and changed where I push/pop, and stuff started showing up (and animating) properly. Of course, the default camera doesn’t seem to be looking at the scene (it’s staring off somewhere), but I’m guessing that’s just yet-another thing I haven’t implemented right. :wink:

There’s SO much ground to cover, and I’m starting from scratch, and trying to NOT build an entire engine. Next up is textures + UV coords, fun!

Thanks for the brain-jog!

-d

4

Collada’s a pretty sophisticated format with lots of useful features. If you want to support everything that’ll take some time. Regarding textures, the spec and schema aren’t 100% clear about how texturing works and this leads to a lot of confusion. In the release notes document for Collada 1.4.1 is an explanation of the proper way to do texturing in Collada.

Good luck and be sure to let us know if you have any other questions.