Set diffuse to blue:
glMaterialfv(GL_FRONT, GL_DIFFUSE, <blue>);
Draw a quad (glBegin()… glEnd())
Set Diffuse to red:
glMaterialfv(GL_FRONT, GL_DIFFUSE, <red>);
Draw another quad (glBegin()… glEnd())
The result is both quads being blue instead of the first blue and the second red. The same problem occurs with ambient and specular.
I’m on 9600 pro catalyst 5.10. I read some posts about people having other similar problems with the built in lighting variables, but I was hoping drivers would’ve caught up by now. Or at least they could give a warning on the info log whenever we’re trying to use a built-in uniform that’s not fully supported? That would’ve saved hours of frustration.
Anyway, I’m guessing the veterans will suggest using my own uniforms instead?
I’ve verified this issue and will file a bug report on it. In the meantime, a workaround (except using uniforms) is to simply call glUseProgramObjectARB() with the same shader again.
If anyone could verify if other drivers have similar problems, I’d appreciate knowing. So I’m guessing the fastest way (right now) would probably be to use attributes…
Are you suggesting to call glGetIntegerv() and glUseProgram() every time a lighting uniform is changed? Or does calling glGetintegerv() in itself actually fix the bug for you?
no the get isnt important
im just using that to emphasize im not actully changing the program.
for error free rendering u need to reset the program after you change the state ie
void UniqueMaterial::flush_UniqueMaterial( void )
{
int i;
g_GL->set_glState( glstate );
if ( g_Program.options.force_coverup_of_driver_bug_HACK )
{
int active_programID;
glGetIntegerv( GL_CURRENT_PROGRAM, &active_programID );
g_GL->UseProgram( GLuint(active_programID) );
if ( g_rm.ogl.current_active_programID != active_programID ) // this'll be picked up elsewhere anyways
{
LOG_ERROR( "GLprogram mismatch" );
}
}
draw meshes