Hi J-S,

Thanks for your detailed answer. Actually, I have been doing quite a lot of shader work and I wanted to be really sure about this. I was hunting a bug and therefore I was studying each line of code.

I was pretty sure that the GLSL is not affected by the attribute but I was wondering if the osg is using it for other purposes.

Btw I am testing for enabled or disabled lights by looking at the values of the light settings ambient, diffuse and specular. When these are 0, I skip the light. This way I don't need an extra uniform for enabled/disabled and it is easy to fall back to fixed functionality. Also, there is the GLSL variable gl_MaxLights in order to determine the no of lights. Apparantly, each OpenGL implementation is using 8 as the max, I have never seen another value... Have you?

Thanks for suggesting ShaderGen to generate the standard lighting shaders! I was not aware of this.

Cheers
Raymond


Jean-Sebastien Guay wrote:
Hello Raymond,

    I have a small question to make sure that I understand the
    lighting properly. I am using GLSL to do my lighting and I would
    like to be 100% sure that the call
    stateSet->setMode(GL_LIGHT0 + id, osg::StateAttribute::ON);
    is not necessary for lighting with GLSL. I assume that this call
    is for fixed functionality OpenGL only, is this correct? Or is it
    used for other purposes too?


You're totally right. When using shaders, you'll need to maintain an integer count of the number of enabled lights (if you take care to always group all your enabled lights together from 0) or a bool array of the state of lights (8 booleans, to say if light at index i [0..7] is enabled or not).

Then in your shader you need to loop from 0 to 7, check if light i is enabled, and do the appropriate calculations depending on light type for that light source.

Or you can do it in some other way, that's just the classic way to emulate the fixed pipeline.

On this site: http://www.mew.cx/glsl/ you can find a tool called "ShaderGen" which lets you play with the different features of the fixed pipeline, and then generates shaders that emulate those features. You can do some various hand-optimizations afterwards, but it's a good starting point if you want to see what it looks like.

Hope this helps,

J-S
--
______________________________________________________
Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com <mailto:jean-sebastien.g...@cm-labs.com>
                       http://whitestar02.webhop.org/
------------------------------------------------------------------------

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

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

Reply via email to