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?
thanx in advance for your time…
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.
thx for having a look at this guys!
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…)