Hi.
i would like to ask if there is a chance in using display lists for bump mapping.
i tried to implement this using display lists as described below:
i build the list (glNewList). i use multitexturing and in the glNewList/glEndList block i add a texture offset based on the light position (using glMultiTexCoord2fARB). but my question is (since i don’t know much about how display lists are rendered and stored):
since i stored an initial texcoord offset, is it possible for it to be “updated” in a glCallList call? i do the lighting calculations in the glNewList/glEndList block. i would like to note that i destroy (free) the vertices from memory when the glNewList/glEndList block ends - so i use the list GLuint to feed glCallList after.
is there something i can do, since the scene doesn’t seem to be “updated” by the light position (the texture coordinate doesn’t change). should i move to vertex arrays to do the job?
If I understand your question correctly, the answer is “no”. You have to pull any commands out of your display list whose parameters need to be altered on a frame-to-frame basis.
However, in this case, you can probably leave your display list alone and use the texture matrix to perturb your offset.
If you can set this “offset” into a parameter of the texture matrix, then yes you can use display lists (as long as you don’t call glLoadIdentity on the GL_TEXTURE matrix during the list, of course).
But for bump-mapping you probably compute extra information per-vertex. If processed in software, you can hardly use a display list. But if you use a vertex program then display list is not a problem at all.
Unfortunately a texture matrix won’t be able to apply the complexities of partial derivative tangent space offsets unless you have a trivial case like an infinite light source and a flat plane. You’ll have to use some other means of dispatching your geometry, but that’s OK, you have options for feeding the graphics system quickly on PCs.
altering the texture matrix is a solution i thought but since i free the vertices after building the list, it won’t help (in other words, the calculations for every frame apply to each vertex and i don’t have them).
using vertex programs is something i cannot do, because my hardware doesn’t support it (i have a tnt2 m64 - based chipset).
so, i guess, vertex arrays are the only solution. btw, i used the code found in nehe tutorials (nehe.gamedev.net, tutorial 22 <- nehe is an incredible site) and it was quite good (considering my hardware (p2@350Mhz w/ tnt2 m64) 30 fps for about 1000 vertices using bump mapping, 2 pass algorithm, but didn’t see the bumps right due to the display list problem…)