Results 1 to 4 of 4

Thread: Forward references

  1. #1
    Junior Member
    Join Date
    May 2007
    Location
    Berlin
    Posts
    2

    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?

    Code :
     <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

  2. #2
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    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.

  3. #3
    Junior Member
    Join Date
    May 2007
    Location
    Berlin
    Posts
    2
    Hi sthomas,

    thanks for your reply.

    Quote Originally Posted by sthomas
    The issue you raise has been discussed before, e.g. here.
    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

  4. #4
    Senior Member
    Join Date
    Aug 2004
    Location
    California
    Posts
    771
    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!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •