I am seeing a nasty render problem on the intel x3100 card, under
linux only. The same card works correctly on windows XP. Nvidia and
ATI cards also work correctly under linux. Has anyone noticed this
sort of problem before? Might there be something wrong with my code,
it seems unlikely at the moment though.

Here are some screen shots that show the lighting way out on linux:
http://jason.spashett.com/pics/gltest/

I setup lighting once:

// Setup lighting
	glEnable(GL_DEPTH_TEST);
	glEnable(GL_TEXTURE_2D);
	glEnable(GL_LIGHTING);
	glDisable(GL_COLOR_MATERIAL);
	GLfloat Ambient[4] = [0.5f, 0.5f, 0.5f, 1.0f];
        GLfloat whiteDiffuse[4] = [1f, 1f, 0.8f, 1.0f];
	GLfloat light_position[4] = [5, 10, 10, 0];
	glLightfv(GL_LIGHT0, GL_POSITION, &light_position[0]);
	glLightfv(GL_LIGHT0, GL_AMBIENT, &Ambient[0]);
	glLightfv(GL_LIGHT0, GL_DIFFUSE, &whiteDiffuse[0]);
	glEnable(GL_LIGHT0);
	glShadeModel(GL_SMOOTH);
	glLightModeli(GL_LIGHT_MODEL_COLOR_CONTROL,
GL_SEPARATE_SPECULAR_COLOR);


Then when drawing the model:


Before geometry output:

m.texture.bind();
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);

And then In a gemetry render loop I use the same material:

// Material properties
GLfloat mat_diffuse[4] = [0.9, 0.9, 0.9, 0];
GLfloat mat_specular[4] = [0.9, 0.9, 0.9, 0];
glMaterialfv(GL_FRONT_AND_BACK, GL_DIFFUSE, &mat_diffuse[0]);
glMaterialfv(GL_FRONT_AND_BACK, GL_SPECULAR, &mat_specular[0]);
glMaterialf(GL_FRONT_AND_BACK, GL_SHININESS, 100);
glVertex3f(x, y, z);

NB - Language is Digital Mars D

Spacen Jasset schrieb:
> I am seeing a nasty render problem on the intel x3100 card, under
> linux only. The same card works correctly on windows XP. Nvidia and
> ATI cards also work correctly under linux. Has anyone noticed this
> sort of problem before? Might there be something wrong with my code,
> it seems unlikely at the moment though.

Well, suppose it's a driver bug - what's your driver version (GL
version, vendor an renderer strings, maybe just post the glxinfo output?)?

Philipp

On Jul 8, 11:02=A0am, Spacen Jasset <jmspash...@gmail.com> wrote:
> Here are some screen shots that show the lighting way out on linux:
>

I think the problem is texture, not lighting. One has texture, one
doesn't.

> Before geometry output:
>
> m.texture.bind();
> glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
> glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
> glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
>

This might be the problem. Some drivers don't like to change the min/
max
filters after you set the texture image. To change the filters they
would have
to recalculate all the mipmaps, etc., and this isn't always easy to
do.

Technically they could do it, but in practice some don't.

> Before geometry output:
>
> m.texture.bind();
> glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
> glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
> glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
>

This might be the problem. Some drivers don't like to change the min/
max filters after you set the texture image.

Oh NO! I have a function that relies on this to work. Luckily noone 
complained before.

Would I have to re-upload all the images again otherwise? <shivers\> 

On Jul 9, 7:33=A0am, fungus <openglMYSO...@artlum.com> wrote:
> On Jul 8, 11:02=A0am, Spacen Jasset <jmspash...@gmail.com> wrote:
>
> > Here are some screen shots that show the lighting way out on linux:
>
> I think the problem is texture, not lighting. One has texture, one
> doesn't.
>
> > Before geometry output:
>
> > m.texture.bind();
> > glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
> > glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
> > glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
>
> This might be the problem. Some drivers don't like to change the min/
> max
> filters after you set the texture image. To change the filters they
> would have
> to recalculate all the mipmaps, etc., and this isn't always easy to
> do.
>
> Technically they could do it, but in practice some don't.

So far this doesn't seem to be the problem - in the screen shot you
can just about see the textures, except they appear over saturated. I
am currently stripping out lots of code down to the minimum to see if
I can find the problem. It doesn't work with texuring disabled either.
But I notice if I resize the SDL window, sometimes I get a specular
like effect, but it's all jagged and horid, nothing like the windows
or nvidia versions. I'll post back if and when I find out any more.

My render is correct (I think):
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) 965GM 4.1.3002 x86/MMX/SSE2
OpenGL version string: 1.4 Mesa 7.0.3-rc2
OpenGL extensions:

Spacen Jasset schrieb:

> My render is correct (I think):
> OpenGL vendor string: Tungsten Graphics, Inc
> OpenGL renderer string: Mesa DRI Intel(R) 965GM 4.1.3002 x86/MMX/SSE2
> OpenGL version string: 1.4 Mesa 7.0.3-rc2
> OpenGL extensions:

You might want to try a newer version, though the only 965 bug (except
for one about fragment shaders and one about sRGB texture readback) in
7.0.3-rc2 mentioned on the mailing list refers to another king of
graphics corruption:
http://pc486.net/screenshot/mesa-7-0-g965-incorrect.png
vs
http://pc486.net/screenshot/mesa-7-0-g965-correct.png

Philipp

"Gernot Frisch" <me@privacy.net> wrote in message 
news:6dml1sF3d7skU1@mid.individual.net...
>
>> Before geometry output:
>>
>> m.texture.bind();
>> glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
>> glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
>> glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
>>
>
> This might be the problem. Some drivers don't like to change the min/
> max filters after you set the texture image.
>
> Oh NO! I have a function that relies on this to work. Luckily noone 
> complained before.
>
> Would I have to re-upload all the images again otherwise? <shivers\>

are your normals normalized? Is there a non-normalizing transform in play ?
It looks like a specular light problem. Do you have separate specular turned 
on ? (you should).

jbw

On 11 Jul, 02:25, "jbwest" <jbw...@comcast.net> wrote:
> "Gernot Frisch" <m...@privacy.net> wrote in message
>
> news:6dml1sF3d7skU1@mid.individual.net...
>
>
>
>
>
> >> Before geometry output:
>
> >> m.texture.bind();
> >> glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
> >> glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
> >> glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
>
> > This might be the problem. Some drivers don't like to change the min/
> > max filters after you set the texture image.
>
> > Oh NO! I have a function that relies on this to work. Luckily noone
> > complained before.
>
> > Would I have to re-upload all the images again otherwise? <shivers\>
>
> are your normals normalized? Is there a non-normalizing transform in play ?
> It looks like a specular light problem. Do you have separate specular turned
> on ? (you should).
>
> jbw

I load the normals from a lightwave .obj file, and I did in the past
check them to make sure they are of length 1. I'll recheck that again
to make sure they are the right length and point the right way and so
on. I'd expect it to not work on all cards if that was wrong though.

I have no scaling transfoms, only translation and rotation. But I
could turn on the automatic normalisation option in opengl I guess.

Interestingly enough when OpenGL Renderer is: GLX Mesa indirect on a
vmware installation the same problem occurs, this means that there is
something wrong in my code doesn't it? As mesa is doing all the
rendering and not using DRI?

Spacen Jasset wrote:

> Interestingly enough when OpenGL Renderer is: GLX Mesa indirect
> on a vmware installation the same problem occurs, this means
> that there is something wrong in my code doesn't it? As mesa is
> doing all the rendering and not using DRI?

"Indirect" just means, that the GLX and X11 network layer is not
bypassed. So it's perfectly possible, that DRI is used.

Wolfgang Draxinger
-- 
E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867