As I sadi before I’m fairly new to collada, so apologies if this all sounds straight forward.
I’m using the integration templates and I’ve managed to get Suzanne (the blender primitive) rendering using the intGeometry template.
I’m now looking at material stuff and I’ve hit a snag.
I’ve got a myGeometry structure that holds all the information from within <geometry> (within <library_gemetries>). The problem is, all the material stuff is within <visual_scene> (within <library_visual_scenes). So, myGeometry knows nothing about materials (which makes sense).
BUT if I have a myMaterials structure that holds the material information, how can I map the right geometry to the right materials? To my knowledge, the order of things is not guaranteed…so I may have geometry data before material data or vice versa.
I’m sure this must be a common problem so I’m hpoing there is a common solution
What are my options here?
There is a late binding method used for this.
The materials and geometry get associated together in the visual scene using <bind_material> and <instance_material> elements.
The COLLADA specification (bind_material chapter) and the release notes do a good job of describing how this linking works. You can find them both at http://www.khronos.org/collada/
There is also a sample document in the www.COLLADA.org/owl test model bank that clearly illustrates this too. its called Multiple_material or multimtl. It’s in the basic samples section.
now some thought about integration templates and the COLLADA DOM. Back in COLLADA 1.3 and earlier when the COLLADA DOM was first being created the integration templates were nice. Things were much more straight forward then. Linking materials was done with a URI straight to the material, for one example. But now in COLLADA 1.4 there are more than twice as many elements making twice as many templates. The linking isn’t as simple, there is a lot of late binding happening now.
The integration templates can still be used, but in order to get geometries with materials you will also need to make a template for <instance_geometry> (or handle it in <node> ). The late binding will need to take place during fromCOLLADAPostProcess().
There are a few reasons why I don’t recommend the integration classes. They are pretty specific issues that the general user probably doesn’t need to worry about. 1. you don’t have control over when objects get read/converted so you will need to rely heavily on fromCOLLADAPostProcess to do anything that may need another converted COLLADA asset. 2. It will convert everything. What I mean about that is if you are loading a COLLADA document with 10 geometries, but the scene only uses 1 of them, the integration classes still get called for all 10 geometries. This is an issue for me because my interests in COLLADA are in asset management and tools. I see an infrastructure where you have a whole document with just the library_geometries and store all your geometries, same with other asset types. Then levels are just small documents that externally reference every object they need while building up a scene.
