Level of detail in Collada

Are there any plans to add native support for LODs in the Collada format? I was thinking it could simply be an attribute on the <mesh> and <skin> elements. For example:


<library_geometries>
    <geometry id="mygeom-lib" name="mygeom">
        <mesh lod="0">
            
        </mesh>
        <mesh lod="1">
            
        </mesh>
    </geometry>
</library_geometries>

Eric Lengyel
Terathon Software

LOD is a case of multiple representation, where you want to associate some extra meta-data so your application can decide which representation to use.
Depending on the algorithm your application use you may need more metadata than just the LOD level, some may use a distance from a bounding sphere, or a projected surface or many other parameters to decide which alternative representation to be used.

Selecting different representation based on the target platform for instance is no different (use this model, or this set of models on PS2, and those on PSP, and those on PS3…). Or selecting different precomputed T-meshs with different optimization parameters.

By design, COLLADA need to be able to handle all the data and metadata necessary for this purpose, but will not mandate how the data is to be used. In other words, if a tool does not know what LOD are, it can still let the user select which representation the user want to edit…

Making this selection at the <mesh> level is one possible way, it has the advantage of referencing any of the representation with a single geometry id. But sometime it is too low level, since the selection may require using different material as well, so you can use a simpler FX when the object is in lower LOD, or when the target platform does not accept shaders… In that case the selection should be done at the <node> level in the scene, or maybe at the <instantiate_scene> level, since the multiple representation choice could be done for the all scene.

Mesh level

<mesh> has already some extra data. So you can already use this to store the meta information you need. In the modeler, the extra data should be available as ‘user property’ and exported/imported in the <extra> of the <mesh>, so this should work transparently.

 
<library_geometries> 
 <geometry id="mygeom-lib" name="mygeom"> 
  <mesh> 
   <extra type='LOD"> 
      <technique profile="some_profile"> 
         <level> 0 </level> 
         <distance_1> ...  
       </technique> 
      </extra> 
    </mesh> 
    <mesh> 
      <extra .. 
   ... 

Node level

At the node level, the selection can be done by using several <instance_geometry> and adding the proper information

 
…  
<scene> 
 ...  
 <node> 
  <instance_geometry url="#lod1"> 
   <extra type='LOD"> 
    <technique profile="some_profile"> 
     <level> 0 </level> 
     <distance_1> ...  
    </technique> 
  </extra> 
  ... 
 
  <instance_geometry url="#lod2"> 
   <extra type='LOD"> 
   ... 
 

Asset consideration

In regards to design, selecting from various representation is a hierarchical asset management issue. You would like to be able to collect all the representations of a given model (parent asset), you would like to know if there are some dependency between the assets (this model was computed from this other model, with this tool …), or what tool and source data was used to create the given representation.

<extra> element can have a <asset> element. This can be used to check the creation date and modification date, which tool was used to create this particular element, and so forth.

Hi there,
Just seen this quite old message, as it relates to something I am facing now.
While I agree that the LOD issue can be tackled in different ways, and even if I understand that COLLADA should not mandate the way to do it, it is also true that probably a default way would help. The LOD case is something that is quite well-defined in the 3D industry; not many software packages use it but some major ones do have native LOD groups. Two examples are Maya and MultiGen’s Creator. And at least two of the most popular file formats for big 3D databases (OpenFlight and OpenSceneGraph) do include a LOD definition, which is basically equivalent. So why not have a “default” meaning for a LOD node in COLLADA, while of course leaving the door open to any custom implementation that people may need?
By the way, just tried exporting a LOD group from Maya to COLLADA and the info of course gets lost.

Thanks,

Luca

Hi Luca,

As you say, LOD is suported by a few tools. The best for now would be to use the COLLADA extension mechanism.

You said that Maya has some support for LOD that you would see exported.
You have a few options:

  • take the source code of the Maya exporter and add this feature. Contribute it to the community. If you open a bug on feeling software bugzilla with the source code attached they will integrated this in their release
  • ask on the feeling software if they could add this feature in a future release
  • or you can contract them to add this feature

Extensions are reviewed periodically as candidates for being part of the standard.

With LOD, the difficulty is going to provide enough information for the application to know when to go from one to another, without mandating a specific run-time behavior.

What would be your idea of a good LOD definition in COLLADA ?

Hi Remi,
If I’ve got it right, you suggest to create an extension to support the LOD. My problem in going that way is that it would be in some way vendor-specific, like the existing extensions (which belong to XSI, Maya, Feeling Software or so).
In my opinion LOD should be defined in the common profile; if we agree that it is a type of info that should be shared and not specific to a given technique, than we can consider it as part of the general COLLADA data model.
Once that is done than the rest is easier. Even adding support for it to the Maya exporter would not be a big issue (and I am ready to help of course). But until that day, we could not export it from Maya and for example read it back in OpenSceneGraph, as they would not share the same custom profile probably.

About the definition, we could do a quick survey but I guess that the definition adopted by OpenFlight, OpenSceneGraph and X3D probably can be merged into a single one as they rely on the same idea. Which is: a LOD is a group node, its children are the various representations. The LOD node has a list of distances at which the switch from one level to the next one is supposed to happen. That’s it. We can then decide the details of how to store the ranges but those 3 representations are basically equivalent. And for example Maya has exactly the same idea so exporting it would be straightforward (I’ve done it already for the OSG exporter by the way).

Hope it helps,

Luca

Yes, that’s the best way to extend COLLADA. Creating an extension first that can be implemented immediately, and then based on how many tools can support this extension, and further discussion in the Khronos group adding this extension in the Specification.

Our philosophy is not to create additional features that tools do not understand, but to create a common language for tools that support a given features.

Note that extensions do not have to be tool specific. They may be created by one vendor, but all other vendors have the right to use this extension, it is just a naming convention.

In my opinion LOD should be defined in the common profile; if we agree that it is a type of info that should be shared and not specific to a given technique, than we can consider it as part of the general COLLADA data model.

I agree this would be preferable. But from what you described it seems that only Maya as support for this. What about Max, XSI, Sketchup ?

Once that is done than the rest is easier. Even adding support for it to the Maya exporter would not be a big issue (and I am ready to help of course). But until that day, we could not export it from Maya and for example read it back in OpenSceneGraph, as they would not share the same custom profile probably.

Why not creating a OpenSceneGraph extension, and adding this extension to the Maya exporter and importer ?

This way the extension can be added to other tools as well. This can be done immediately without having to wait for the specification to change. The extensions are closely examined by the working group for each new specification for inclusion in the schema.

About the definition, we could do a quick survey but I guess that the definition adopted by OpenFlight, OpenSceneGraph and X3D probably can be merged into a single one as they rely on the same idea. Which is: a LOD is a group node, its children are the various representations. The LOD node has a list of distances at which the switch from one level to the next one is supposed to happen. That’s it. We can then decide the details of how to store the ranges but those 3 representations are basically equivalent. And for example Maya has exactly the same idea so exporting it would be straightforward (I’ve done it already for the OSG exporter by the way).

That’s probably not the way to do this in COLLADA, since COLLADA does not have the notion of ‘group node’ or any other scene graph specific behavior. This is by design, COLLADA is not a scene graph. A <node> in COLLADA is simply a frame of reference (local coordinate system), and has no other meanings.
It is by design that COLLADA is staying away from run-time/application specific behavior. There is no plan to add ‘group node’ ‘lod node’ ‘switch node’ or anything the like in COLLADA.

On the other hand, having multiple representation of the same object is something that should be more clearly defined in COLLADA. I talked to Mark about this, and we think that this should be done as an instancing mechanism.

For instance (no pun intended! ), COLLADA provides <instance_geometry> that enable the instance of only one possible representation. Maybe another instance element can be created <instance_multiple_geometry> that will enable listing several possible representations with additional metadata for the application to decide what to do with this. distance could be one of those.

What do you think ?

Hi again,
Very quickly, a few replies to some points you raised.

But from what you described it seems that only Maya as support for this. What about Max, XSI, Sketchup ?

Not true that only Maya supports it; for example Multigen’s Creator has it since long ago (it’s the main tool for producing OpenFlight databases); and so do many tools - free and commercial ones - producing OSG databases. I have no clue about about Max, XSI and Sketchup though.

Why not creating a OpenSceneGraph extension, and adding this extension to the Maya exporter and importer ?

Good point; actually, to make it even more general, it could be just SceneGraph so it would refer to a functionality more than to an existing product. Does this make sense? If not then let’s stick to the OpenSceneGraph one.

COLLADA does not have the notion of ‘group node’ or any other scene graph specific behavior

True, but the node element can contain other node ones, so there is a hierarchy in there. We could think of something to add the extra info needed by a LOD.

Maybe another instance element can be created <instance_multiple_geometry> that will enable listing several possible representations with additional metadata for the application to decide what to do with this. distance could be one of those.

Wow, that sounds interesting, probably more than handling the LOD stuff as a special node. So, basicaly, you say we could add support for having multiple geometry instances for a given parent node. I see that the “bind_material” field is in the instance_geometry element; if designed properly, even materials/shaders could be different in the various instances then. So, basically, we need a new element that, for a given parent node, could hold multiple instances, each of which with its range and material info. Cool… And I guess your suggestion is to start by having that in some extension for now, submit it and then see if it can be moved into the common profile later, right?

Luca

Yes.
And you do not even have to modify the exporter code, you may just create a conditioner that create this <extra> LOD node, from naming convention for example. If you do it correctly, then applications that do not know about this extension can still display the highest detail model and ignore the rest.


  <instance_geometry url="HighResGeometry">
    <bind_material...
   <extra>
     <technique profile="SceneGraphLOD"">
       <lod level="1" distance="123" url="Geometry_level_1">
         <bind_material...
       </lod>
       <lod..
      </technique>
    </extra>
   </instance>