Question about common profile state settings

Is there a standard way to specify values in the common profile for state settings corresponding to the following OpenGL functions?

glShadeModel (for setting flat vs. gouraud shading)
glPolygonMode (for setting solid/wireframe/points rendering)

Thanks,
Steve

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 answers or suggestions?

Another question then: what’s the standard way of incorporating texture transforms? If there is no standard mechanism for it, I’ll probably try to put it in <bind_material> somewhere.

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?

AFAIK, double_sided is not a standard COLLADA parameter, it exist in the MAYA extra technique only.

Look at the “Common Glossary” section on page 3-4 of the 1.4.1 spec. DOUBLE_SIDED is listed as a standard name value for a <param> element.

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.

-Daniel

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.

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.

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.

-Andy

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.

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.

I submitted bugs 15, 16, and 17 to the Khronos bugzilla. Bug 15 deals with texture transforms and DCC apps.

Also I think I’ve had all of my questions answered. The answer is that I need to be using <profile_GLSL/CG> for what I want. Thanks for everyone’s help.

Actually now that I think about it, the thing that sucks about this is that if I import/export such a model from a dcc tool it’s probably going to throw out my <profile_GLSL> and just export a <profile_COMMON>, so I’ll lose my platform-specific render information in the process.

We’re trying to treat Collada as a source format, whereby we ship a bunch of Collada models with our software and our users can edit those models in any Collada-supporting package. The farther I get along with this the less confident I am that this is going to work.

Have your company put pressure on the plug-in implementors to make it so they don’t drop the extra data. They aren’t supposed to but until we have the conformance test finished we have no way to strictly test and enforce this rule.
The plugin implementors sometimes just need to be pushed by users so they can prioritize features.

-Andy

First let me add support for <profile_GLSL> to our converter and importer, then I’ll see exactly what the dcc apps do with it (throw it out I’m sure). Then I’ll submit bugs/feature requests to see if we can get them to round-trip that data properly.