Re: [osg-users] The Collada plugin and transparency

[Roger James]

Jason Daly wrote: Roger James wrote: I was assuming that because the lighting equation (blinn)  has already been applied in the pipeline before textures are applied, that if we wanted to use a texture map to supply the ambient terms to that equation, then the lighting equation would have to be somehow re-implemented in a fragment shader. I did not think the the fixed functionality could be configured to handle it, especially the contributions from light sources. I am happy to be wrong in this. Well, thinking about it more, in order to get it mathematically correct, you're probably right.  However, fixed-function multitexturing can give a reasonable facsimile (especially with an ambient occlusion map in the ambient channel). The "right" way to implement all of this is probably to write a COLLADA Blinn shader (as well as one for Phong, one for Lambert, etc.) and avoid fixed function altogether.  Unfortunately, this leads to problems if users want to make use of their own shaders. I think I will just assume that if a translucent texture is present in the ambient channel that it contains an ambient map and blend it in as texture unit 1 (0 is used for diffuse). According to both the spec and Mark's book the common profile of Collada FX is supposed to represent an abstraction for a "platform independent fixed-function shader". However in the abscence of any significant definition of what this abstract shader/pipeline actually is, the specification appears to suggest that texture values are used as input to the lighting process (blinn, lambert,etc.). Obviously this is not the way OpenGL works. I am not sure that this is what was intended :-). It is the source of much of the confusion (well mine at least!). The transparency bit is the bit that needs fixing. We are just not handling transparent textures at the moment. I would really appreciate your input in this area, as I feel that I am just wandering about in the wilderness on it at the moment. I don't really remember enough about how this works.  I know there are issues and subtle differences regarding A_ONE and RGB_ZERO modes, and I thought I even heard the spec for this changed between 1.4 and 1.5 (I wrote my code for 1.4).  I'll tell you what I did in my code, but I don't have time to research this further right now. Yes, some more opaque values have been added. There is a misprint in the spec on all of them that suggests that the default value has changed. I have been told that this is not the case, and the schema document should be taken as authorative on this. In my code, (which is probably technically wrong, but seems to work most of the time) I check the opaque setting on the transparent color.  If it's A_ONE, I use the transparency value as the alpha on the material (the OpenGL material, that is).  If it's RGB_ZERO, and transparency is specified as a color, I average the transparency color's RGB values and set the material's alpha to 1 minus the average (this is probably a best-effort kind of hack).  If transparency is a texture (an alpha map), I ignore it, since it's not possible to support in fixed-function (at least I don't think it is). Of course, none of this has anything to do with whether or not the diffuse texture has alpha.  If the diffuse texture has an alpha channel, this needs to be honored as well.  I check for this with a call to osg::Image::isImageTranslucent() on the image from the texture in question. That sounds like a reasonable approach. However, I have thought some more about the approach I was suggesting and have modified it slightly. I think I will try that and if it gives too many problems fall back to your approach. I will attempt to pseudo code my latest thinking: if (transparent or transparency element present in the technique) {     // Turn on the OpenGL blender     Calculate a blending factor using transparent and transparency according to the "opaque" mode in force.     // Decide whether to use GL_SRC_XXX or GL_CONSTANT _XXX in the OpenGL blender     if (the calculated factor would mean opacity when  applied)        Use the relevant blend factor from the incoming lit and textured fragment     else        Use the previously calculated blending factor as a constant blend factor } I would appreciate any comments you have, time permitting of course. For anyone else reading this. Just a reminder that we are talking about transparent and transparency within the confines of the common profile which does not allow multiple techniques in an effect. I suspect that in profiles that do allow multiple techniques there are many more issues, the decalling of materials and textures being just one I can think of. Roger

_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org