SERIOUS DEFECT: profile_COMMON and colors, vertex colors, and why choose either/or?

A serious problem with Collada is the profile_COMMON.

Now if this profile was only for visualization in modeling software, it would not be such a problem. Just a fallback mode. However in the real world, there is no software that implements the Cg or OpenGL based profiles. Autodesk’s fleet might, but I don’t exactly get the impression that it does so. This itself is a larger problem that I’ll cover in another discussion thread.

Now! in profile_COMMON. The 1.5 spec doesn’t mention how it should interpret Vertex-Colors. It would be impossible for an implementer to make this call with any degree of confidence.

Furthermore, fx_common_color_or_texture_type forces basic importers/exporters to prioritize material properties over textures. It’s an impossible situation. ALL modeling software has both a color, and a texture, for these states. The relationship is simple. The texel is scaled by the color.

Normally it is colorvertex-colortexel-color=color (diffuse/ambient/and so on)

Why or?

[code=Specification – FX Reference 8-53 April 2008]
Child Elements
Note: Exactly one of the child elements COLOR, PARAM, or TEXTURE must appear. They are mutually exclusive.



Why on earth? Is it only so PARAM can not be described by the XML scheme to not be unbounded? Why not 0-or-1 COLOR and 0-or-1 TEXTURE and also something for vertex-color where applicable? Blender's plugin does not consider profile_CG, or profile_OpenGL, etc. So it's an untenable situation.

Blender's import/export plugins, which are its default cannot even accommodate this. Direct3D also had Material properties, including colors, alongside textures. And this is common practice.


@Admins, the forum software would stop at nothing to keep me from posting this. Maybe the company names looked like spam? Anyway, posting the first paragraph, and then editing the rest in defeated this confounding [i]feature[/i] for better or worse.

IMO the whole effect system is quite unusable. It’s very hard to implement a common system between different applications. But COLLADA makes a lot of effort to design exactly the opposite - to target very specific low level rendering based on OpenGL. Which can’t even work truly natively in any application, since there is much more application dependent stuff in a GLSL/CG shader. OK, Maya has a cgfx material, but this is not a native material for the Viewport. There true shaders now are using specific fragment XML language. Is this going to be supported with COLLADA - no of course… When you import COLLADA effect, can you render it with any sofware/Mental Ray/VRay - no…

To support native shaders, they should target high level material description with some application specific extensions, since there is just no other way. The host application should decide how to render this thing - OpenGL, DirectX, software, ray tracing, renderman. But COLLADA’s common profile is probably the most underdeveloped and simplified part of the spec. What Blinn shader means for example? This is just a reflection model - it’s not really a shader model. I know Maya has this issue in it’s old software renderer, but nowadays we have much more advanced materials. The situation with lighting is similar - it’s very simplified and archaic. For example the spot light is controlled by a spot exponent. This is OpenGL 1 stuff. Most applications use inner/outer cone. They export garbage in this exponent, and sometimes they may decide to add own profile (which of course nobody really knows or supports).
Should we talk about the opacity/transparency mess - for the half of the exported assets, you don’t know what really you are reading…
So the whole shading system is terrible, even the basics are not there. Personally, I develop my own format to store the scene data. But I still need to import as much data as possible from other applications. I don’t want to write exporters for everything, i.e. this is what COLLADA was designed for. But it barely works. Also Autodesk has FBX, Cinema 4d has Melange, Rhino has OpenNURBS. They maybe not perfect, but still better solutions. You know exactly what to expect from the library, you know who supports it. It’s eve even less work for me. For 3 day I have basic C4D importer working including skinning. And the melange library is really not that popular and lacks sample code. For 3 day I can’t even start working with any open source COLLADA library. And I have read most of the COLLADA specs in the past so I know what I’m doing…

COLLADA targets the real-time 3-D problem space. So it’s perfectly reasonable to have profiles for these high-level shader models. I believe these other softwares can embed their information in the COLLADA files, via extra/technique. The trouble is that everyone is coming to COLLADA with a very myopic mentality, that comes precisely from this view or writing importers and exporters. Blender cannot even retain the FX profiles, much less render them. It should be doing both. And it should also be retaining profiles that are put in the files by other software.

COLLADA is multi-representational. That means every software you open the document in, can generate its on profiles, and you as an editor may have to configure every profile from scratch, so that they match, and if you change the file up considerably, some of the profile data may get lost in the shuffle, and you may find yourself repairing it by hand. What this means though, is that every software that claims to do COLLADA, that is a persistent editor, really must be able to read and transform the file losslessly. That’s not mere import/export. It’s like welcoming into your software, a second (or third) side-by-side internal data-model. It’s not enough to import the COLLADA file. It has to be loaded, and stay in the editor, and every change needs to be reflected in the COLLADA document, and then saved afterward. There is no import/export if COLLADA is done correctly. That view is incompatible with COLLADA as described. Most file formats would not warrant meeting such demands, but COLLADA says it’s going to be the one-and-only exchange format (or lets hope so) and so at least in its case, 3-D software really has to respect that it’s not a traditional file format. So far I don’t believe anyone has done this.

PS: What you describe is 3-D file format hell. It’s how we got here in the first place. Sheer human laziness and lack of vision. 3-D is very complicated. But music, images, movies, and so on, have many more-or-less standard, virtually non-proprietary formats, without baggage. 3-D has none. And no standards. That there is no 3-D exchange format, I think is the biggest problem for 3-D out there. I wish when COLLADA was conceived, the parties involved would have recognized this, as the real important problem for the field, rather than the one COLLADA expressly sets out to solve. What COLLADA says it’s for is an important problem, but it’s not totemic.