Jason Daly wrote:
Smeenk, R.J.M. (Roland) wrote:Roland, As Jason says, attempting to map the Collada FX common profile to OpenGL fixed functionality is a design goal rather than an absolute. I apologise that I have used the term "fixed functionality" loosely to refer to both the OpenGL FFP and the abstract fixed functionality referred to in the Collada spec. "The <profile_COMMON> elements encapsulate all the values and declarations for a platform-independent fixed-function shader. All platforms are required to support <profile_COMMON>. <profile_COMMON> effects are designed to be used as the reliable fallback when no other profile is recognized by the current effects runtime." If you also take into account Mark Barnes statement in his book.. "profile_COMMON (is) for basic interchange between digital content creation (DCC) tools" then you can see that Collada's abstract understanding of fixed functionality could be quite different from OpenGL's concrete implementation. For example the "fixed functionality" of a DCC might in fact be a ray tracer implemented in software, in fact it could even be implementeed entirely in programmable OpenGL shaders! The problems we have been wrestling with stem from the lack of a clear definition of what Collada's abstract "fixed functionality" model is. Your intrepretation of the spec clearly highlights this, and it is very close to the intrepretation I have been trying to map into a concrete OpenGL implementation (and trying to obey our design goals whilst doing this). Correct me if I am wrong but I believe your interpretation is that the diffuse, ambient etc. terms of a particular technique define the source of a colour term (either a texture map or a fixed value) that is used as input to the lighting equation of that technique. The result of this equation is the colour of the material (it is probably easier to think of this as a fragment colour in OpenGL terms). Collada defines colour as a RGBA value. So this intrepration would seem to imply that the alpha component of, for example, the diffuse element should be passed through the lighting equation and contribute to the alpha component of the result, and I think this is the only point where we differ. The main problem this model gives us is that when we try and map this interpretation to OpenGL, whether or not we use OpenGL fixed or programmable functionality, is that the OpenGL pipeline assumes that the lighting equation has been applied prior to the application of any textures. Applying textures before lighting may not have been what the Collada designers intended, who knows, because the model is not documented. Regarding the use of the transparent element, because the Collada designers come from a DCC background I have assumed that the transparent colour or texture would be handled in a similar way to that which it is in a DCC tool such as Maya. That is the the transparent colour is used soley to provide a single component greyscale (alpha) transparency map which is applied to the material in some way (usually as a way of decalling in a diffuse texture in the top layer of a multi layer material). Because I have not been able to determine what this "way" is I have left it as unimplemented for the time being. Should we use it to replace the materials alpha after the lighting computation, or before it, should we blend it . I do not know, and would like further input from anyone on this. Sorry for this long winded rant, but I wanted to provide as much background information as I could for further discussion. Roger |
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
