I’m busy writing a collada importer for C++ (not using the colladaDom but rather a sax parser) and i cant find any info on whether data sources can be used across mesh tags or geometry tags?
Generally, yes because the mechanism is URI based, however your example is demonstrating a different error, so … “no”.
You must bind a VERTEX semantic input to a <vertices> element, so your example is flawed.
Also, e.g. a <mesh> element requires at least one <source> and one <vertices> element. The design intention here is that the mesh contains at least the identities of all of its own vertices (POSITION semantic).
my example was a quick job just to highlight what i meant, i should have taken the effort of putting in another source for something like normals.
so basically meshes do not encapsulate their own sources and may use data from any source element present in the DAE file which begs the question why encapsulate data sources inside of geometric objects to start with and not simply have a library_sources element.
okay, that kinda throws a tiny spanner in the works as i will need to link up my accessors to my data source arrays after parsing the entire file and not after parsing each accessor tag.
In theory yes and most obviously between meshes. In practice, I don’t think you’ll encounter such sharing.
Nice catch. A <library_sources> was considered but consensus was not reached. People preferred to have their data sources co-located with their mesh, animation, etc… Hence even the <input> elements are constrained to use URI fragments (i.e. same document).
Yes, and in general, resolution of any URI, IDREF, or sid_ref should happen after all the resources are known. I.e. any element with an id attribute could be buffered and resolved using a late-binding idiom. On first access the buffer could be marshaled and deleted.