Forward references

A <COLLADA> element contains a bunch of lists of <library_*> elements.

Apparently there is no order defined on those <library_*> elements - is this correct? This would imho somehow defeat the support for SAX-style parsing since it means that potentially every read data has to be kept in memory. (Ok, I could write read data out in another file format but…)

So, is the following (pseudo) code orderwise correct or is there some constraint on the order in some specification I haven’t found yet?

 <COLLADA>
  <asset/>
  <library_geometries>
    <geometry id="cube">
     ...
      <polygons ... material="cube_mat">
     ...
    </geometry>
  </library_geometries>
  <library_nodes>
   <node id="node">
    <instance_geometry url="#cube">
     <bind_material>
       ...
       <instance_material symbol="cube_mat" target="still_to_come">
     </bind_material>
    </instance_geometry>
   </node>
  <library_nodes>
  <library_materials>
   <material id="still_to_come">...</material>
  </library_materials>
  <library_effects>...</library_effects>
  ...
 </COLLADA>

The problem here is that even after instantiating the geometry its instances are still incomplete - they lack the “real” materials, which are finally defined much later on.

Thanks for any hints
Ali

Hi, welcome to COLLADA!

The issue you raise has been discussed before, e.g. here. Not specifying a strict sequential ordering of the different libraries does make things more difficult for SAX-style parsing, but in general the designers have preferred not to limit the flexibility of the format to make parsing easier.

I imagine these issues can usually be resolved with some additional bookkeeping during parsing. In the case of <instance_geometry> referencing <material>s or even <geometry> elements that haven’t been defined yet, you could store the references and then resolve them to specific objects in your runtime later, after the entire document has been loaded. It’s an additional burden but it should allow you to correctly do SAX-style parsing of COLLADA documents.

Hi sthomas,

thanks for your reply.

Yeah, I missed that one when skimming through the threads.

Not specifying a strict sequential ordering of the different libraries does make things more difficult for SAX-style parsing, but in general the designers have preferred not to limit the flexibility of the format to make parsing easier.

Agreed - but there are two points which made me curious

(1) all dae files I have seen so far do follow this order
<library_effects/>
<library_materials/>
<library_geometries/>
<library_visual_scenes/>

(2) there is already an order constraint on the <COLLADA>'s children
<asset/>
[<library_>]
<scene/>
<extra/>

I imagine these issues can usually be resolved with some additional bookkeeping during parsing.

Yes, but first I wanted to make sure that this additional work is not superfluous just because I was missing something, ie had overlooked something.

Cheers
Ali

COLLADA is highly referential and so there will always be some degree of forward referencing to other elements. The Proxy design pattern can be helpful in implementing late-binding requirements in a uniform manner.

In a SAX parser you can build up a structure of proxy objects that will resolve values on-demand, after the all the desired information is actually read.

Hopefully that approach makes sense!