lighting with ARB_texture_env_combine/dot3 and ARB_vertex_program


this is not really related to OpenGL content, I would simply like to know your opinion about this.

I am planning to rework the terrain engine (driving simulation) which currently does not even use multitexturing, and all lighting is done with standard OpenGL vertex lighting, to use per pixel lighting/bump mapping with the above mentioned extensions (no register combiners, no cg, no glslang etc.), with diffuse and specular lighting, the possibility of using a gloss map, and reflections (the sky would reflect on the “wet” parts of the street.

I am planning to do the geometry setup stuff with ARB_vertex_program (NOT NV_vertex_program), all data is inside of display lists (which I would not like to change).

Does this sound like a reasonable idea (I think at least it will look much better than it actually does), or are the techniques I mentioned so outdated that it would be better to not even start it and learn cg and glslang or something?


With the “ARB_vertex_program”, it’s not required to use a display list cuz the extension has some functions to do the same as vertex array, etc …

The functions are :


Maybe am I wrong but it seems more logical to use the ARB function for the vertex program instead of display list.

the “problem” is that the program does alread exist and is already with display lists, and I feel no urge to rework all this to use vertex arrays. Also, I still feel like display lists are the fastest way of drawing. So I am planning to keep the display lists and do vertex setup with vertex programs.


OK, but if you do that, the vertex program will not be used.

I think that you need to rewrite the code for using ARB extension cuz only initialising the ARB program will not be used with display list.

what you are saying is that vertex programs will not be used when using display lists. That, I have to say, I really doubt, and have never heard of it. As far as I know, when enabling a vertex program, it will be used when drawing with display lists the same as it will be when drawing with immediate calls.

Probably it didn’t become clear that the geometry is inside of the display lists, not the vertex program .


Ok, so if you’re sure, no problem.

>>and I feel no urge to rework all this to
>>use vertex arrays.
come on, an additional code path isn’t that much work.
or use immediatemode, while developing; apart from that, i’m pretty sure that you are goint to drop the support for dispaly lists in the future anyway, i assume.

but, i wouldn’t back, too, that GL_vp also works with display lists; you better take a look into the specification, to be sure.

[This message has been edited by DJSnow (edited 12-27-2003).]

It makes absolutely no difference how you specify your vertexdata for ARB_VP. It takes one Vertex, does some stuff with it and outputs one vertex, no matter if you send it immediate, in a DL, via VA or a VBO. So if you only use static geometry, don’t drop support for DLs, as they still are the most efficent way to store data and statechanges on the gfxcard and moreovere can be dynamically altered with a VP/VS.

[This message has been edited by PanzerSchreck (edited 12-27-2003).]

Panzerknacker what you said is exactly what I think. I do not understand why everyone despises display lists, as they are so easy to set up and so efficient and fast.


Altough not OT : Exactly what you say, most people tell you to use VBOs instead of DLs, because of the sole fact that they’re newer. But those people totally forget that DLs have the big advantage that all statechanges are also compiled into them and that there’s definateley no better way to optimise static rendering. But the good thing is, that you can now with the help of ARB_VP/VShader even use displaylists for dynamic geometry. I mean VBOs aren’t bad, as I use them myself, but DLs are still the best choice for static scenarios.