Quote:Original post by Anonymous Poster
Also you don't use the modelview matrix. Is this also intentional?
Should it not be
gl_Position = gl_ModelViewProjectionMatrix*mix(gl_Vertex,gl_SecondaryColor,interpolation);
Not really intentional per se, just a throwback from when I started this project. See, when I first began this I knew nothing of OpenGL, or indeed- game programming. I've since learned that using the Projection Matrix in this way is a BAD idea, but because the code still worked fine- i didn't feel the need to change it.
Quote:the fragcoord.z for a fragment of a triangle depends on the the three vertexpos of the triangle
True. I supposed I wasn't 100% accurate in saying that the vertices didn't affect it.
Quote:the lod of the texture selected also depends on the vertexpos.
Perhaps this has something do with the use of the projection matrix.. Though the vertex position ends up in the correct place, so it should work- in theory.
I'll try using the projection matrix ONLY to set up the perspective view, clip planes etc.. and use the modelview for world / model transformations instead. Maybe this may help the shader determine the correct LOD.
Quote:Its really not clear from the image of the column, what are the artifacts and what's part of the texture.
As I said, its difficult to spot in a static image- but trust me, its there alright. When you see it moving you will notice the abrupt changes in pixel color that occur when you attempt to use a big texture in a small amount of screen space, without mipmapping enabled.
Quote:You should probably render them using fixed function see how it looks and then proceed to eliminate. And use some debug textures, which could easily show the problem.
I think I will give that a shot. But first I'll try changing my use of the OpenGL matrices and see what difference it makes.
BTW, does anyone have any links that shows what equations OpenGL uses to determine mipmap LODS ? If I can't solve this problem then perhaps I could implement an LOD scheme manually in the fragment shader. Maybe I could get things working that way..
Thanks for your help,
Darragh
As you can see, everything bar the column by the wall is mipmapped. The players gun is also not mipmapped too since it uses the same GLSL program to render as the column, but it is too close to see the effects.
Oddly, the walls and ceiling / floor remain unaffected by the mipmapping problem- even though they are also rendered using a GLSL shader (for fog). The main difference between the GLSL programs for model rendering and wall rendering is that the model rendering program contains both a vertex (for interpolating keyframes) and fragment program (for fog), the wall rendering program contains only a fragment program to do the fog effect.
This leads me to the conclusion that the problem only occurs when using vertex shaders. Further evidence of this lies in another shader- for doing water effects. This shader has both a vertex and fragment program too, and again- no mipmapping occurs.
So there must be some part of the fixed functionality pipeline which I am not replacing in my vertex programs.. I've looked at the GLSL spec but unfortunately I couldn't get anything from it which would help my problem. I am setting up my mipmapping correctly using the GLU routines for building mipmaps and then using the texture filter GL_LINEAR, GL_LINEAR_MIPMAP_LINEAR throughout the program. The problem must lie within my vertex shaders.. Below is the both the vertex and fragment code for the model rendering shader:
- VERTEX PROGRAM -
