FYI: I'm trying to Khronos to update COLLADA's homepage. Please Join Me!

I haven’t posted about this yet, but for a while now I’ve been talking outside of this forum about a need to publish a new official document on COLLADA’s homepage.

So far I have two MAJOR CONCERNS for COLLADA, if it’s ever to be a workable standard. The thought behind this effort is to change COLLADA without affecting the schema, and without doing anything that requires parties at Khronos be in agreement since it seems like if changing COLLADA was so simple it would’ve been changed by now many times.

Concern 1) Morph-animations are not a thing. <morph> is thought to be complementary to <skin> but <skin> is for animation, but <morph> is for what? Well it turns out not animation, or it cannot do animation anyway. Dramatic works require a morph-animation feature. Without that COLLADA is a nonstarter.

Exhibit A)

Concern 2) I started working with Physics a few days ago. If you thought COLLADA was bad. You probably haven’t looked at Physics yet! Because woah darling, Physics takes the cake. It has a whole host of problems. But there’s just one that is really in need of addressing. The others are less significant, and probably cannot be addressed. The short version is a Physics document cannot use <instance_node> and that many of Physics’ <instance_*> elements use URIs instead of SIDREFs in a way that just doesn’t make any sense at all, because it’s meaningless for the Physics simulation to refer to an external document, and to only use the # fragment part of the URI for internal references is so restrictive that it means <instance_node> cannot be used, and that SIDs cannot be used to address nodes.

Exhibit B)

To address concern 1) my recommendation is just to let animations target the morph weights in their <source>. They can either target the <float_array> by ID or the <source> by ID which would work like an <instance_> element by following the <accessor> URL to the external <float_array>. To achieve this I want to say that A) if no SID is found, then it decays into an ID. This also solves ambiguous wording in the manual which fails to distinguish between SIDs and IDs. And that a <_array> is not special. It is a value like anything else, and can be the target of an animation. It’s not raw data. Functionally there is no difference. It’s targetable. That doesn’t necessarily mean you should target it. But yes, if you want to animate a single vertex or something, then you can do that. (Maybe software will honor it, maybe it won’t.)

To address concern 2) my recommendation is to treat the degenerate/meaningless anyURI references like HTML treats its # fragments. That is a # in a URL can either refer to an “id” or a “title” attribute. To let the Physics node bindings work as SIDREFs as they clearly should have worked from ALWAYS the new rule is that a # fragment that refers to a COLLADA region can be a SIDREF. This is probably not useful outside of being a bandaid for Physics. A #SIDREF should just begin with #. It needs to be case-sensitive to be able to compare the reference as a unique-string (since the target itself doesn’t describe the path to it) and full URLs are not case-sensitive. And furthermore external SIDREFs are meaningless in a normal context.

(EDITED: I wrote case-INsensitive before. I meant that SIDREFs should be equal regardless of case. Not that the case should be considered. Which means “insenstive” in one intuitive sense of the word, but not in terms of string-comparisons, where insensitive means being sensitive to the case: that’s a little messed up if you think about it.)

Both of these fixes deal with interpreting SIDREF references. The Physics #SIDREF is a completely legit URI. But like I say, where it’s needed a URI doesn’t even make sense. COLLADA Physics is a misfire. If we cannot get these corrections instituted then we can only conclude someone made Khronos sabotage COLLADA. THESE ARE VERY SERIOUS ALLEGATIONS :wink:

Do you mean wiki home page or official page (specs page)?

I’ve parsed skin, morph but I’ve not rendered them yet, also I haven’t worked on Physics yet, so at this time I’m afraid I can’t help much about skin, morph. After rendered images I’ll work on skin, morph and animations ASAP. It seems I’m a little slow :confused:

Don’t both skin and morph are for animation?

After rendering morph and skin animations then I’ll write more reasonable things :slight_smile:

Well you’d think so, but either for COLLADA the answer is No, or they neglected to include animation. What it does officially is just blend two or more meshes to make a new mesh. So you could use it to reference two or more faces for example, and create a new face by blending the weights. But it would just be a static mesh. You couldn’t make the face come to life. Not by morphing it. See the link provided. It says so. (Still there is code in the COLLADA-DOM RT for morphing. So the milieu of people working on COLLADA were thinking about it. They just were not working on it 1/10th as hard or as seriously–maybe competently–as I would have had I been given the opportunity!)

I’ve been going through the archives here looking for any information on Physics since there’s nothing about it anywhere. What I didn’t expect to find is most of the team chatter around COLLADA-DOM is actually in this forum instead of the forum! So I’ve been learning a few new things about COLLADA-DOM’s history. The Physics is very difficult to deal with, but I am trying to formulate the best possible interoperable interpretation in the new RT package. In addition to the link above, there’s another that I didn’t bookmark that highlights the general problem with constraints in the Physics system. I have to figure out how to apply the constraints in the next few days. Even if you can get past binding to the nodes, the constraints are linked via URLs, which is basically meaningless, so the best you can do is to apply some black magic heuristic to instantiating them. I have to figure that out. There is no correct answer. But hopefully there is a very convoluted best answer.

I would describe COLLADA in many ways as a hair-brained scheme. It is what it is though. I think it’s a black sheep compared to Khronos’s other technology prescriptions. I wouldn’t be surprised if some of the others are as funky as COLLADA, but it really could have been so much much better. And I think Khronos should own it. And try to clean up their image by it. That said, there are parts of it that could’ve been much, much worse. And probably the things I think are good and bad about COLLADA would run counter to the facile criticisms that I imagine most would levy at it.

EDITED: Also @recpas, I am very glad I can work on the RT part of COLLADA-DOM. Because honestly there are many parts of COLLADA that are poorly defined, so much so, that if I couldn’t default to how the RT code did it, I’d find myself with even more conundrums. IOW if I had to try to do it from “scratch” I think it would be very difficult going. I hope the new COLLADA-DOM will reach people, so that they can use the new RT package to see how things are (probably) supposed to work, so that they can get started much more easily.


The <rigid_constraint> examples in the manual use #URLs that fill out the fragment with a SID??? You have to wonder what the authors were smoking in their pipes at some point.

If a URL can be a #SID, then it only stands to reason that it can be a #SIDREF also, since a URL can be anything technically. What’s more is the URL refers either to a <rigid_body> (in the same <physics_model> or anywhere?) or a <node> … but <rigid_body> doesn’t even have an “id” attribute, so an #ID fragment cannot even refer to it!! That means, that by definition almost, an ID is a valid SID or a SID is a valid ID (but in what order?) and that even though <instance_node> doesn’t have an “id” attribute, it can still be #ID addressed by a #SID fragment.

It’s all messed up. I don’t know why anyone thought having all of these possibilities could be helpful. It’s almost like sabotage. Industrial sabotage?

(This make resolving URIs difficult. COLLADA-DOM had treated a URI fragment as referring to an ID. Now it will have to be able to refer to a SID or even a SIDREF? Fortunately I added something to COLLADA-DOM so its schemas can be configured to elevate other types of attributes to ID-like status. But I stopped short of involving that in the legacy ID/SID query APIs.)