Thanks for all of the replies. I think there is a mix of backgrounds here so I thought maybe I’d rephrase with a small example. I think we have slightly different definitions of the same words for better or worse.

In this example an artist has created a simple model for game engine X. This model consists of 3 objects linked in a hierarchical fashion such that there is only one root object, object A, and objects B and C are children of that object A. Here is the visual scene element from the DAE exported from Max 7 for such a model where:

object A = Box01

object B = Sphere01

object C = Cone01

Also, the pivot points have NOT been modified in Max yet by the artists so there are no “*_PIVOT” nodes in the DAE output from Max. Here it is:

<visual_scene id=“unnamed_scene” name=“unnamed_scene”>

<node id=“Box01” name=“Box01”>

<matrix>1 0 0 1.68131 0 1 0 1.1417 0 0 1 44.5881 0 0 0 1</matrix>

<instance_geometry url="#Box01-obj"></instance_geometry>

<node id=“Sphere01” name=“Sphere01”>

<matrix>1 0 0 -50.2823 0 1 0 19.5414 0 0 1 -44.5881 0 0 0 1</matrix>

<instance_geometry url="#Sphere01-obj"></instance_geometry>

</node>

<node id=“Cone01” name=“Cone01”>

<matrix>1 0 0 50.6662 0 1 0 4.14335 0 0 1 -44.5881 0 0 0 1</matrix>

<instance_geometry url="#Cone01-obj"></instance_geometry>

</node>

</node>

</visual_scene>

So, a little more info, engine X internally will want to represent this model as 3 nodes connected in a hierarchical fashion very similar to Collada’s. In this case the import is very simple. Each Collada node contains a geometry instance and a corresponding matrix so the conversion process is almost 1 to 1. The engine then does a depth first traversal of the 3 node tree and calculates the worlds transforms of each node by using a standard matrix stack approach. All is good.

Now, say that the artists moves the pivot point of object B (the sphere) let’s say…so now there are 4 nodes output in the Collada DAE. Here it is. The sphere has a child node that is called “Sphere01_PIVOT” that contains the geometry now.

<visual_scene id=“unnamed_scene” name=“unnamed_scene”>

<node id=“Box01” name=“Box01”>

<matrix>1 0 0 1.68131 0 1 0 1.1417 0 0 1 44.5881 0 0 0 1</matrix>

<instance_geometry url="#Box01-obj"></instance_geometry>

<node id=“Sphere01” name=“Sphere01”>

<matrix>1 0 0 7.71774 0 1 0 19.5414 0 0 1 -44.5881 0 0 0 1</matrix>

<node id=“Sphere01_PIVOT” name=“Sphere01_PIVOT”>

<matrix>1 0 0 -58 0 1 0 0 0 0 1 0 0 0 0 1</matrix>

<instance_geometry url="#Sphere01-obj"></instance_geometry>

</node>

</node>

<node id=“Cone01” name=“Cone01”>

<matrix>1 0 0 50.6662 0 1 0 4.14335 0 0 1 -44.5881 0 0 0 1</matrix>

<instance_geometry url="#Cone01-obj"></instance_geometry>

</node>

</node>

</visual_scene>

So, remember that the engine still will want to represent this model with only 3 geometry nodes…so when the collada parser gets to the “Sphere01” node it sees that it has no geometry so it creates a dummy node for the engine. A dummy node is a node in the engine representing only transform, but no geometrical data. No prob…it then gets to the “Sphere01_PIVOT” node and says “Aha…a geometrical child node exists here so let’s create a brand new node with geometry.” So now, the engine internal representation has 4 nodes, when really only 3 nodes are necessary in a optimal, real time representation of this 3 part model.

But now, the engine internal representation of the model has 4 nodes when really we could optimize this and say, well yeah, the model has 4 nodes, but really we could just define the verts in the space of the pivot and collapse the model to 3 parts.

So this can easily be extended to a 50 part model where the artists adjusts all the pivot points and the collada DAE now has a 100 element hierarchy, but really in real time, we could get away with 50 collapsed nodes.

Maybe the whole confusion for me is that…the engine is way more optimized that the DAE represenation of a model. Is there a way to collapse pivot nodes in Max/Maya before export that would take our 4 part model back to a 3 part model?

This is what I meant in my earlier posts, all engines will want to collapse here and there and ingore certain nodes. But for a DAE parser to make these decisions it has to know that the “*_PIVOT" node can really just be collapsed by using the matrix in the "*_PIVOT” node to transform the verts back into that space, thereby eliminating the need for a superfluous “pivot” node.

I hope I’ve explained this well. I think writing an engine that can use the Collada structure would not be hard, but would be wasteful in the case of adjusting a pivot point. I’m not sure what “freeze transforms” does in Maya or if Max has a similar function…maybe it’s just a matter of the artists pressing a button to “re-bake” the pivots…I dont’ know.

Thanks for all of your responses. This Collada is fun stuff. What I said may have been what you guys are saying but I had to put it into an example.

So now the question is, what else can the parser do but look at the names of objects to know that it has “_PIVOT” attached and therefore can optimize. It seems like there is no other meta-data the parser could use to make this decision.

Regards,