Hi! , I am programming a custom DAE loader, up to now I went as far as loading all the basic geommetry structure, but I’m having some troubles storing “source” tags
as far as I understand, all elements in the DAE document that have an “id” attribute can be referenced from other tags, now my question is:
all the “identifiable” tags have global scope along the entire document? (so, any tag can reference any other tag, anywhere in the document)
or do they have a local scope in the document? (references are valid only in the leaf of the tree were they are defined)
Also, I’m having a little trouble implementing the indirect referencing of position > vertex source inside a mesh:
why this indirect referencing?, and, how should I treat “vertices” element? as a global resource, like the “source” tag? or just as a special indirect reference that must be processed locally inside the mesh element?
thanks in advance
Vic
Hey Vic,
Let me try to address your questions.
First, there are a few different ways COLLADA refers to data and tags within itself. The main one is by URI. A URI is very powerful and can target many different things. Check out rfc3986 for more detailed information about that.
The main way we use it is to target things with id’s. local URI targets can be shorthanded as ‘#someid’. That really stands for ‘thisdocument#someid’. So any element can be referenced from anywhere within the document and its not constrained to it’s subtree. There is a type that we use called URIFragment which we created for situations where we want to limit the scope of a URI. These are the ones you are encountering in the geometry input elements. We define a URIFragment as just the ‘#someid’ so you cannot reference elements from other documents. This allows us to keep certain data (like mesh vertex positions) local.
We do provide a local scope targetting method with the sid attribute. The rules for this are defined in the Addressing Syntax section of the COLLADA specification. Its mainly used in animation and effect/material binding.
Now for your other question. We hear this time and time again.
The reason the <vertices> element exists is because a vertex needs to be a concrete entity in the mesh. Often times you only see positions as an imput of vertices but nothing is stoping you from defining verts with positions, normals, binormals, etc. etc.
All the DCC tools treat vertices as individual entities, thats why you can select them and do stuff to them individually. But heres the one explanation that usually gets people to understand. What happens if you have two vertices in the same position, lets say a skinned face where the lips touch. If all you have is position values how can you tell the two vertices apart when you are loading? You would most likely see they are the same position and threat them as the same vert. Thats wrong because even though they have the same position now, when the face animates you want the mouth to separate which requires them to be seperate verts.
I hope that helps and I didn’t ramble on too much,
-Andy