I was very glad to see that the initial spec includes the ability to reference data externally. I am curious how extensively can this be used? It seems pretty flexible, but let just ask some dumb questions: For instance, it looks like a vert array or material can be referenced? What about an asset, or other higher level type such as a library? I’m hoping this sort of referencing is possible because it really opens the door to better asset structuring and management.
Such support for referencing could also help in another area. The speed of reading/writing xml keeps coming up throughout this forum. Speed will always be an issue, but I think there is a solution outside of the straight brute force approach. It is possible to export data more intelligently, by structuring the assets in the pipeline in a manner that makes sense. Rather than cramming everything you need into a level file and exporting it into a single massive xml file, why not break the file up into multiple sections? This could be done either within the source file, meaning the file produces multiple outputs, or by separating the contents of the source file into multiple source files, each producing their own output. Then they are sewn together using the <Asset> tag, and some references to the output.
A couple of other things that would help in structuring assets are an <include> and <substitution> tag.
< include url="file://c:/file.xml" />
< include >
url= <substitution name="user_path_var" />
</ include >
Another note: Regarding the <extra> tag, it seems like this is a very important and useful tag that should not be limited to being attached to a node. I’d like to be able to put <extra> meta data all over the place, from <assets> to materials, etc. Is there a reason not to do this? Or is there another way to supply meta data that I have overlooked?
It is as flexible as you might expect from URI based mechnisms. COLLADA documents are not included into one “compilation unit” per se. Rather, COLLADA resources are referenced by URI producing a different resource model then typical compiler #include composition.
COLLADA resources are referenced by name (ID really) when the URI contains a simple ID fragment. More flexible resource location, within a document, would use a XPath fragment. The document is just one level of asset for COLLADA but is in itself not a referenced resource as a whole.
A <library> isn’t referenced. Rather items in a library are referenced via URI. The degree to which a set of hyperlinked resources are spread over a medium of documents, servers, and networks is up the content authors, the tools they use and the particular use-cases.
Just as in HTML, sometimes it is better to read (and navigate) a single monolithic document and other times a distributed document is preferred.
In COLLADA the sections exist to seperate resources into distinct documents like <library> and <scene> but it’s not our intent to compose a compilation unit out of them.
The reason not to do this with <extra> at this time is because <technique> elements are containing the information more readily. See my replies HERE.
I had initially seen the technique tag and assumed its purpose to be rather limited. According to the specification, the technique element is a:
…method or procedure used to produce the visual appearance of a geometric object.
I’m looking for something that will allow non-visual data to be associated with either a geometric object, or something slightly more abstract.
The deffinition in the spec seems to be a very narrow and specific. Has the technique element’s purpose evolved since the release of the first spec?
Slightly related to this is (and I know, the animation spec is not finished yet, but…) the issue of time based event type data that needs to be associated with an animation. Will this also be handled with the technique tag?
This area seems to be rather complicated because, unlike tranformational animation, or other value/curve based animation, there is no well defined standard for representing such data in most commercial packages. Because of this, most studios use some strange home brewed method for doing this. For instance, we use a completely custom built system in Maya that would never be recognized by a publicly provided exporter. This will pose significant difficulties for: 1) those who are writing the universal COLLADA compliant exporters and 2) COLLADA in general as an interchange format.
On a lighter note, I still have some questions about structuring assets. The asset tag has a limited number and type of child elements allowed. What about a more abstract or flexible asset type? Something that would allow higher level organization of a project’s data. Something who’s purpose is to manage other assets, files, or generic data. It could be used to contain settings, paths, platform specific instructions, etc. I realize this may be beyond the purview of the initial COLLADA spec, but using a homogenous filetype to organize all of a project’s data could really simplify management of large projects. (You guys are just doing such a good job with the spec that it seems like a good fit )
Yes the technique element was originally introduced to differentiate shaders within the material element. Currently techniques are more widely useful, describing alternative representations of texture, material, source, object modifer and camera information. Source elements hold data for, among other things, geometry.
You can build geometry with as many input elements as you like. Not all of those inputs need be visual data. However, we are starting to incorporate nonvisual physics data into the COLLADA schema and the representation approaches from that effort may be applicable to your use cases as well.