Im reading threw the second lesson on BSPs at www.gametutorials.com and it does lighting by creating a texture and having OGL display two textures on top of each other. Why not just use something like glLightfv to do the lighting? This seems like a better way to go. Could someone please explain to me why they do this and if they agree with me in using glLightfv?
Thanks
Nuke
If I understand you correctly they are using preprocessed shadow maps (or lightmaps). This gives you a few benefits.
If the hardware has multitexture but not HW T&L then you get a benefit in the speed of your lighting (which is rather pointless these days).
You can precalculate your lighting for static lights and shadows. You can also have very large polygons without suffering from the interpolation problems you get from GL’s way of creating the light. Plus you get a “per pixel” form of lighting calculation rather than per vertex (which is the cause of the problems you get with large polys and native GL lighting).
you get a rather rough form of per pixel lighting and shadows without using any extension, even without using opengl at all… this was introduces with quake 1, wich had “per pixel lighting” and shadows in software rendering mode.
Im a bit confused, so the way gametutorials does lighting is faster but only on old gfx cards, would that mean the lighting would be better if I just have ogl do it? I want to create a BSP engine that is as good as if not better then the Q3A one.
Light-map lighting is more accurage, and able to take into account shadows. Vertex lighting (which is what glLight* and its ilk use) is much less accurate.
heh ok thx
Originally posted by nukem:
Why not just use something like glLightfv to do the lighting?
you see, if you’ll be using glLight* for huge level with many rooms/walls/etc, you’ll have some troubles if you need, say, to put a light in one room, and want to leave the room that is nearby dark, as OpenGL doesn’t really make difference if there’s another polygon between one polygon and a light source, and spreads the light anywhere according to settled parameters of that particular light. Also there’re really few seperate light sources available in OpenGL(<8 or so), so you can go out of them easily.
So the lightmaps are really useful when you’re going to put some light on a small amount of surfaces if you have many different areas of surfaces available.
If i go wrong with this, please somebody correct me.
Another way of looking at it is to say that OpenGLs light model is only a local one, and lightmaps can simulate a global light model. What is the difference between local and global lighting? When doing local lighting on an object, the amount light a vertex receives is calculated as a relation between the light source and the objects vertex. The local light model does not take the positions of other objects into account when doing this calculation. So it does not “see” if there are any other objects blocking the light. With a local light model like OpenGLs you cannot for example have a box cast a shadow onto the floor.
In a global light model, this is possible since here you consider all geometry in the scene when doing your lighting calculations. With lightmaps the lighting information is calculated using a global lighting model like ‘Radiosity’ and is then stored in textures, which are then put on top of the normal textures at run-time. The quality of the shadows you get with lightmaps is of course dependent on the resolution of the lightmap textures used. The downside of lightmaps is, that they are static, i.e. you cannot moved an object and make the shadow change at runtime, since that would require a recalculation of the lightmap texture.
So how would you render lighting for models, like MD3 MD2 MDL?
Well, there are number of options for doing shadows for models. I would probably go with shadow volumes, which is what Doom III and Tenebrae for Quake are using. Shadow Volumes give very good visual results and have the ability to self shadow (a concave object casting shadow onto itself).
The drawback of using shadow volumes is that they are quite expensive, since you have to draw the scene twice for each light source in the scene. Rendering the shadow volumes themselves can also be expensive if they are complex enough. So if you are using shadow volumes, you will probably have to limit the number of lights in each scene or do some other trick to bring the fill rate down.