Questions about specs

[recp]

1. Can every element (or every node) have different UP axis? Or one UP axis for entire document?
2. Camera UP axis: https://forums.khronos.org/showthread.php/13262-COLLADA-1-5-Camera-Orientation
3. Spotlight: https://github.com/KhronosGroup/glTF/issues/824

[m-7761]

I answered 3 in your link. 2 (I should check in at those forums) I would say that "always looks at -Z" depends on <up_axis> to define -Z. There's an implicit transform in the camera that must be dealt with regardless since -Z depends on it. 1 is pretty straightforward, but only elements with <asset> in them and some elements like I think it would not make sense to consider their <up_axis> because <source> is already very bad in so far as there is no single place that describes its contents and there is no "library_sources" and it's just very bad design IMO.

[recp]

@mick-p1982 thanks for your comments and answers, I'll try to understand (1), I think spec should only allow 1 up_axis for entire document, this would make coord sys homogeneous

[m-7761]

You have to think of it like a web of documents. And a webserver using a REST protocol could generate DAE resources on the fly drawing from many places, like webpages are created. In that case the idea of a "file" is pretty stupid and outmoded. You have to think bigger. It's more like the WWW and HTML related technologies.

[recp]

I got it, good example! But the part I don't understand is that should I add extra transforms (to node) becaue of different up_axis-es ? Check this to see example: https://github.com/KhronosGroup/OpenCOLLADA/issues/517 .

[m-7761]

The up_axis isn't technically a transform. See the Update_Matrix example in the COLLADA-DOM RT component's code for one way to do it (flipping the scalar components of <translate> for example) but there are different ways with different advantages. I think doing it at the source is best. If you try to do it based on if the parent and child have different <up_axis> you'll run into some troubles with instancing and controllers that tend to accumulate maintenance wise, and sometimes there's not a clear parent-and-child relationship.

[recp]

It's been a while. I'm going to close this.

COLLADA seems as inactive standard: https://www.khronos.org/developers So I'll change my direction about implementing all details in COLLADA spec. I may drop some features which are probably CG and GLSL profiles and some other platform (especially dead ones) dependent features to keep importer interface simple...

I'll work on my own file format: http://github.com/recp/asset-xchange in the future. Probably AssetKit will be the official importer of that format. It will be binary format like JPEG.

[m-7761]

@recp Inactivity can be a good thing. I don't think it means abandoned.

EDITED: For example glTF documents openly discuss COLLADA interoperability (and also the need for a distinction in terms of what each standard's problem domain actually is, and how they differ.)

[recp]

@mick-p1982 hope it is a good thing.

My goal was to implement all details of both 1.4.1 and 1.5+. But since the spec is not clear enough and buggy, and since I can't get clarifications or answers, I think it is time to think on what I should do now.

I think all profiles except commonProfile must be dropped. Actually all platform dependent things must be dropped in importer side. Because;

• CG is dead.
• Apple deprecated OpenGL and I think Khronos may abandon it in favor of Vulkan in the future. I will switch to Metal on Apple platform, to DirectX/Vulkan on other platforms. OpenGL is dead for me. So GLSL, GLES, GLES2 profiles are redundant.

Lets not maintain dead platforms and platform specific features in exchange format. I do not know why they are in the spec as standard in the first place. In the new format I'll consider all of these...

I will continue to implement remain parts of COLLADA. I learned a lot. There are lot of things to say but I prefer to not say here, in a closed issue :)

[m-7761]

Cg is very close to HLSL. Nvidia restored the documentation last I checked, so perhaps it's not so dead, after backlash. GLSL is essential. Yes, it's very flawed, but unless implemented it's a fools errand to amend. GLES2 is WebGL.

My recommendation is to develop soft standards for COLLADA in the noncommercial sector, that will inform future editions, once competent implementations exist. The COMMON (geometry) profile is not useful for anything. I think it can be improved a little with some recommendations I developed that allows textures to be modulated with colors (with subscript based semantics) so that it looks more like standard basic material systems, and because using 8-bit textures as colors is too lossy, memory hungry, and artist unfriendly.

OpenVG and also OpenGL ES don't have desktop implementations. So these are bigger failures than COLLADA in my book. Khronos leaves implementations to others. COLLADA is pure software, and after the survey of what should be included in its description, there is nothing left to do with it. So it's inactive.

[recp]

The COMMON profile[s] can be extended via extensions. If an engine want to embed platform specific shaders, it can embed whatever it want to extra element. So I think there is no need such platform specific profiles. But COLLADA could defined a new universal shader language similar to GLSL. Render engines could translate that shader language to GLSL/HLSL. This is what I'm planning for shaders in the future. Same for MathML, COLLADA could only use some equations and operators for formulas, instead it forces us to support all MathML elements, another XML scheme with its rules.

I liked the formula idea instead of pre-defined curve, I will try to extend this idea in the future.

COLLADA material system is too old. Khronos could update COLLADA after glTF 2.0, they did not :-S

After my render engine's (https://github.com/recp/gk) initial version has been released then there are lot of things I will/want work on (including game engine and modeling/animation tool...), all will be written in C99 ;). Each one of these will help to improve others. This is why I think I can create a good exchange/runtime format in the future.

Khronos leaves implementations to others. COLLADA is pure software, and after the survey of what should be included in its description, there is nothing left to do with it. So it's inactive.

I really do not understand how things work at Khronos side. Maybe there are too many members and maybe this is their common decision, I do not know. The obvious thing is that COLLADA appears to be dead 😔

[m-7761]

<extra> isn't useful for a COLLADA ecosystem. It's an anti-pattern. It's a spot fix for private use. It defeats the purpose of having a "COMMON" pathway. Going your own way is counterproductive. And means you go alone.

[recp]

isn't useful for a COLLADA ecosystem. It's an anti-pattern. It's a spot fix for private use.

It can help where common profile does not enough to describe/define assets. Multiple tools/engines can use same extension for same purpose.

It defeats the purpose of having a "COMMON" pathway.

I think the exchange format itself must be COMMON, not only some pieces called "common".

Going your own way is counterproductive. And means you go alone.

We are already alone with abandoned spec, aren't we? I may try to create small community or use it only for myself, we will see it in the future. One way or another, it will be my tools' and engines' exchange format (internal or public). So it will worth it, nothing to lose.

AssetKit still supports (and will support) COLLADA and glTF. In the future, it may support more common formats e.g. obj as extension to original library (not in core). My own format is a special case. Of course I will update design of library in favor of new format...

[m-7761]

Yes, everyone is alone (reinventing the wheel.) And that's what defines failure. Insert "Insanity is making the same mistake/not realizing it forever" quote here.