The Khronos Group - a non-profit industry consortium to develop, publish and promote open standard, royalty-free media authoring and acceleration standards for desktop and handheld devices, combined with conformance qualification programs for platform and device interoperability.

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

These forum categories are here only for historical purposes. Please post all new questions either in the new COLLADA category, or on StackOverflow.

Actually I have a couple more questions. I'm looking at the "Common Glossary" section on page 3-4 of the 1.4.1 spec. It lists DOUBLE_SIDED as having type "float". That should probably be bool, right? I'll submit a bug if necessary.

Also, I'm a bit confused about how to properly use a parameter such as DOUBLE_SIDED. Does anyone have an example of how to specify that a material is double sided?

No, the common profile is not intended to match to a specific API. It is a collaberation by the DCC vendors to match their basic rendering system. Infact it has features like refraction which map best only to raytracers.

By default in most DCC apps (and OpenGL) models are already considered double sided. (ie no culling). Most lighting calculations though are based on the goemetry normals so the back side of the polygons will usually appear in black.

No there is no flat shaded model profile_COMMON.
Is this a request for the feature?
If so you are the first person I have heard requesting it.
Typically this feature can be implimented by simply making the normal at each face-vertex the same as the face's normal. That can make phong, blinn, or lambert act just like flat. This is how the modern "sections" of APIs support flat shading.

I suggest that if you are interested in more OpenGL control then you should use profile_GLSL or profile_CG.

By default in most DCC apps (and OpenGL) models are already considered double sided. (ie no culling). Most lighting calculations though are based on the goemetry normals so the back side of the polygons will usually appear in black.

Ok, so in Collada everything is double-sided by default? For double-sided objects I wouldn't allow the incorrect normals to be used for the back faces. Instead I'll set glLightModeli(GL_LIGHT_MODEL_TWO_SIDE, GL_TRUE) to make sure that OpenGL reverses the normals for the back faces so that lighting works correctly.

Regardless, I'm still trying to figure out how to set that DOUBLE_SIDED parameter though, because at times I need the back-faces completely culled out. The dcc apps all do their own thing with that parameter it seems, but that should really be a standard setting IMO.

No there is no flat shaded model profile_COMMON.
Is this a request for the feature?

No, I was just asking if there's a standard way of specifying values for those parameters in the common profile. I understand that few people probably need that data, so I'll just put it in my own <extra> block. I need to support it for backward compatibility with our old modeling format (we're transitioning to Collada).

Typically this feature can be implimented by simply making the normal at each face-vertex the same as the face's normal.

Yes but that won't always yield the exact same results (e.g. if you have a point light source), and it doesn't work nicely with some forms of geometry, such as triangle strips.

I suggest that if you are interested in more OpenGL control then you should use profile_GLSL or profile_CG.

Agreed. Unfortunately due to limitations in our rendering architecture and target platforms that are beyond my control I have to get as much mileage out of the fixed-function pipeline as possible.

Does anyone have any idea about texture coordinate transformations? Doing some tests with Max, it seems that ColladaMax just throws out any texture coordinate transformation data when exporting to Collada. These transformations absolutely should be standardized in the Collada spec IMO, and supported by the dcc apps of course.

I suggest that if you are interested in more OpenGL control then you should use profile_GLSL or profile_CG.

Agreed. Unfortunately due to limitations in our rendering architecture and target platforms that are beyond my control I have to get as much mileage out of the fixed-function pipeline as possible.

Using the CG or GLSL profile doesn't mean you have to use shaders. You can describe fixed function pipelines in OGL with both profiles.

Originally Posted by sthomas

Does anyone have any idea about texture coordinate transformations? Doing some tests with Max, it seems that ColladaMax just throws out any texture coordinate transformation data when exporting to Collada. These transformations absolutely should be standardized in the Collada spec IMO, and supported by the dcc apps of course.

I think that currently the only way to do that would be with shaders. I think this may be accomplished with the effect syndication which is a new feature being added in 1.4.2. Unfortunately 1.4.2 wont be out for a while so that doesn't really help you much.

You should enter this as a feature request in the bugzilla and we can look into seeing if syndication can solve this or possibly adding it to COLLADA another way.

Ok, looking over <profile_GLSL/CG> in the schema it's apparent that everything I want access to is accessible from those profiles, including cull face setting, shade model, and polygon mode, so that's what I need to be using.

Originally Posted by alorino

Using the CG or GLSL profile doesn't mean you have to use shaders. You can describe fixed function pipelines in OGL with both profiles.

Good point. For some reason I though that using profile_GLSL/CG meant that you absolutely had to use shaders. But I can just look at the <newparam>s, find the info I want based on the <semantic> value, and use those as my GL material settings, ignoring any <code> or <include> elements.