Nested Asset

My reading of the spec says that I should be able to nest some asset specifiers as needed, in my case to supply a different up_axis for different pieces of geometry— I have some “hard-wired” geometry that I want to supply with a fixed up-axis for convenience, vs the overall up-axis that can change to match user’s preference in the app. So I have this:

<geometry id="StdThing-geometry">
  <asset>
<created>2010-10-10T10:10:10Z</created>
<modified>2010-10-10T10:10:10Z</modified>
<up_axis>Z_UP</up_axis>
  </asset>
  <mesh>
  ....

Any problems with that? xsi mod tool crashes when it is present.

Looks valid.

Nesting assets that redefine units and up-axis is probably not widely supported however as those are passive transforms that have to be applied to all the affected data… i.e. more programming effort.

ANYTHING that is not going to be supported 100% should not be in the standard — the existence of this kind of thing makes the standard very problematic, possibly useless. If I can’t write a COLLADA file that can be read by any compliant reader, why bother? It seems I have to guess what features are supported or not, what idiomatic structures are supported, to have some chance of my files being readable by other packages. I smashed my head against the wall for a while before I learned that the vertices element can’t really be used as it was intended, for example.

Having to re-target the writer for different packages is dumb. It’s like having to broadcast the same TV program 13 different times, one for TVs from each TV manufacturer, with a rewrite required whenever a new manufacturer arrives.

It’s better to have a small simple understandable standard core that is implemented 100% by readers, than something that must be configured based on the idiosyncracies of the reader. If there was ONLY y-up or z-up, for example, some writers might have to be a little more complicated, but it would work because they would have to get it right each time. And readers would be simpler, only one case, and thereby more reliable also. It’s a simplified viewpoint, I know, but yes, I’m frustrated. I’ve been trying to guess what is going to be readable amongst multiple coherence-tested COLLADA files for 2 weeks or so now.

For anyone to have a compliant reader implementation, they have to join the Khronos Adopters Program and make their software pass the conformance test suite. Software that passes will support the Baseline conformance level at a minimum.

The call has gone out from Khronos to encourage (demand) implementers to strive for and achieve conformance. That process is ongoing.

Posts like yours are understandable, given the lack of conformance amongst the current implementations, and I hope adds to the voice of the users that demand conformance. They deserve it.

From the lack of entries, I’m thinking that the total count of compliant readers is zero, right? What’s the best one in a usable commercial product? (something like max, maya, lightwave, C4D, …)

FWIW, I sent email to the address mentioned on the COLLADA tweet about compliance testing. No response in about a week.

C4D or Softimage might be doing the best job amongst the modeling apps.

The FBX dialect is common to the apps you listed although its deficient in many areas, according to its own documentation.

I don’t use twitter… what email address?