I know there is a section in one of the Collada PDFs that lists these basic divisions or domains of Collada.
I may be leaving one out. Core is essentially geometry and animation. I do know know off the top of my head if it includes IK, or if that is considered Physics. FX is materials, textures, and shaders. Lights and Cameras are Core, even though they feel a little FX-y. Physics is everything else, unless I am forgetting?
Now! The big problem with Collada in the wild is FX.
Most software implements Core. Can handle import and export at least, even if it makes no attempt to preserve the contents of the file…
But FX is where things break down. Dumb software doesn’t know which profile to pick if there is more than one. Most won’t prompt. And none that I’ve found venture outside of profile_COMMON.
Ignoring Physics, here is a problem.
In theory Collada could be used to link documents. So in theory an FX oriented piece of software, could link a file with FX information, to a file that is purely Core. Since 3D modeling software knows what to do with Core generally, this could be a way to work around the poor support for the FX feature set. And would free the FX/shaders oriented visualization software from needing to provide a 3D modeling feature set. And the 3D modelers then who are never implementing FX could just continue in this way.
Except Collada cannot make these kinds of links, because FX and Core are not orthogonal to each other. At best the linking document can include <instance_geometry> but inside this element is <bind_material>. So this can work in a simple case, however <instance_geometry> goes inside of <node> and so to do this you cannot have nodes. You’d have to instance the nodes in the linked document one by one, but then you cannot change the material of the geometry–or that is, implement FX properly–with <instance_node>!
THERE may be another option. I don’t know. I was surprised to notice the <bind_material> can also appear under <instance_controller> which is something I’d not considered until I just looked up bind_material just right now! :doh:
Nevertheless, I think it’s a good design principal to try to make these divisions/domains completely orthogonal to one another. It allows applications to only implement one of them at a time. It’s something to consider in future versions. Either as new ways of organizing elements, or by making the original ways obsolete.
(edited: here by “applications to only implement one” I mean that the applications will alter the files they touch. So the XML files could in principal be broken up so that applications that can only be trusted with Core can only alter the file with the Core elements, and so on. Most likely applications that do Core/Physics are likely to have poor FX support. And applications that do FX may not have any modeling or physics support, and limited animation playback if any.)
Now: I have to do more research into using <bind_material> with <instance_controller> I have not yet studied carefully the Controller elements. I will be very, very pleased if it’s possible to wrap geometry in a controller and use it this way. But I’ve learned better than to get my hopes up