I don’t know if it’s a bug in my code or what, but when I enable separate specular, and also use multitexturing, my objects appear overly bright. Nearly white. Only the most darkest areas appear yellowish.
When using a single texture, everything is as expected.
Is there an incompatibility, as seems to mention in the extension registry :
" There is much concern that this extension may not be compatible with
the future direction of OpenGL with regards to better lighting and
shading models. Until those impacts are resolved, serious
consideration should be given before adding to the interface
specified herein (for example, allowing the user to specify a
second input color)."
if you use multitexturing, you set up your own combiner mode, and that means you have to calculate the lighting on your own as well. that is rather simple, because with the separate specular ext, by a big chance you have the secondary color ext as well, that means you should have GL_SECONDARY_COLOR_EXT/ARB/NV/whatever as color source for the combiners.
what you have to set up is something in this way:
out = primary*(multitexture(tex0,tex1,…)) + secondary;
now, if you can it, or not, only depends on the power of the combiners and the multitexture setup… what do you use? tex env? register combiners? anything else? what multitexturing you set up? simple multiplying? dot3? something else?
Thanks dave, but there is absolutely no way to may this work without going vendor specific.
The problem comes from ARB_texture_env_combine not supporting secondary_color. Using multitexturing without the combine works correctly.
What I dont understand is why there is an over brightness effect. It should in fact give identical results to when separate_specular is off.
It could be a bug with NV not properly running the ARB_texture_env_combine on there register combiners.
V-Man: you should check your specular settings. If lights’ specular is white and if material’s specular is white, then yes you may have really bright areas. However, if you move the viewpoint you should notice that this intensity changes because specular contribution is viewpoint-dependant.
davepermen: secondary color may not be an argument for texture combiners since secondary color is taken in account after the texturing stage.
Neither the GL_EXT_separate_specular_color nor GL_EXT_secondary_color nor GL_ARB/EXT_texture_env_combine nor OpenGL1.4 specification allow GL_SECONDARY_COLOR as an argument for glTexEnv, only GL_PRIMARY_COLOR is allowed. Though, it could be a nice addition and maybe further extensions will expose that feature.
Looks like it’s working now. I dont really know what the problem was because I cant reproduce it. I’m assuming it had something to do with anisotropy. I may have passed a value of 0.0
The specular term is added after the texture combiner stage, so not having the specular is not a problem.
Originally posted by V-man:
[b]Is there an incompatibility, as seems to mention in the extension registry :
" There is much concern that this extension may not be compatible with
the future direction of OpenGL with regards to better lighting and
shading models. Until those impacts are resolved, serious
consideration should be given before adding to the interface
specified herein (for example, allowing the user to specify a
second input color)."
Help![/b]
The example you cite was the concern of the freaks that wanted per-pixel lighting back in 1998 (or whenever), and didn’t think that separate specular was worth pursuing.
Heh, that would be SGI. I remember this being an HP proposed extension and SGI had something on the drawing board that had a monolithic fragment lighting equation and they pushed that instead. I always thought separate specular was a worthwhile extension.
There’s something to be said for the ease of programmability of the fragment lighting extensions but the way things have evolved in hardware is infinitely better. I’m surprised there hasn’t been a simple wrapper for OpenGL fragment lighting on top of various extensions yet. Maybe with the ARB fragment stuff it will come. Something like:
// Warning this feature reserves use of the following pipeline stages
// blah blah
gluFragmentLight(GLU_FRAGMENT_LIGHT0, GL_LIGHT_COLOR, blah blah…);
It’s always puzzled me why, at the point the vertex array extension was introduced, the arb went for this mad entry-point proliferation. By this I mean, why glVertexPointer/glNormalPointer/glTexCoordPointer/glColorPointer/glSecondaryColorPointer ???
Why didn’t they just use a single glAttribPointer with some new constants, such as GL_VERTEX_ARRAY,GL_NORMAL_ARRAY,GL_TEXCOORD_ARRAY,GL_COLOR_ARRAY,GL_COLOR2_ARRAY ?
Sort of like the original NV vertex program extension?
It must have occured to them that we may want to extend the number of attribute streams in a more manageable/logical manner?
[This message has been edited by knackered (edited 01-11-2003).]
Originally posted by vincoof: davepermen: secondary color may not be an argument for texture combiners since secondary color is taken in account after the texturing stage.
Neither the GL_EXT_separate_specular_color nor GL_EXT_secondary_color nor GL_ARB/EXT_texture_env_combine nor OpenGL1.4 specification allow GL_SECONDARY_COLOR as an argument for glTexEnv, only GL_PRIMARY_COLOR is allowed. Though, it could be a nice addition and maybe further extensions will expose that feature.
hm… too much gf2 register combiner fuzed my brain (no knacky, i was not talking about my radeon, i talked about the standard pipeline… thats thanks to nvidias rc that i messed it up…)
i thought of the same as my lighting in standard gl dissapeared as i played with texenv and set to replace… so i thought thats the same that once you set up combiners in multittexturing you have to modulate manually with diffuse, and add manually the specular… oh well…
