How do lights work?

Started by
5 comments, last by ChaosWars 17 years, 7 months ago
I don't mean lighting in OpenGL as such, that's pretty much covered in lighting tutorials :) I mean, how does one do lighting in a game engine? I've read that OpenGL is kimited to 8 hardware lights, but that can't mean that you are limited to 8 lights in your game. I've seen/mapped levels which have way more, so evidently that's not right. How does lighting work then? Do you write a software implementation of your lighting? Is the openGL hardware lighting just there for RAD purposes? Or do you have to render the scene multiple times if you have more that 8 lights in a level? Inquring minds want to know ;)
Advertisement
Nobody uses fixed function lights in professional application. The most common approach is to use multipass algorithm (ona pass per light) with shaders enabled. Back in the days people also used precomputed lightmaps.
if (time() == $) { $ = 0; }
Quote:Original post by ChaosWars
I've read that OpenGL is kimited to 8 hardware lights, but that can't mean that you are limited to 8 lights in your game.


Thats 8 lights PER VERTEX.
Quote:Original post by Lord Faron
Nobody uses fixed function lights in professional application. The most common approach is to use multipass algorithm (ona pass per light) with shaders enabled. Back in the days people also used precomputed lightmaps.


So how you one go about doing that? Would you, say, write a fragment shader for whatever model you are rendering using values from lights in your world/level that affect the model? And am I right in this case that you wouldn't have to use OpenGL instructions as glEnable(GL_LIGHTING)?
Quote:Original post by ChaosWars
Quote:Original post by Lord Faron
Nobody uses fixed function lights in professional application. The most common approach is to use multipass algorithm (ona pass per light) with shaders enabled. Back in the days people also used precomputed lightmaps.


So how you one go about doing that? Would you, say, write a fragment shader for whatever model you are rendering using values from lights in your world/level that affect the model? And am I right in this case that you wouldn't have to use OpenGL instructions as glEnable(GL_LIGHTING)?


Exactly. Nowdays everything is done in shaders. If you want to make a professional game engine forget about fixed function.
if (time() == $) { $ = 0; }
You can switch out the lights at runtime; as phantom said the limitation applies per-vertex, not globally.
Quote:Original post by Ravuya
You can switch out the lights at runtime; as phantom said the limitation applies per-vertex, not globally.


Yes, but that way you are still lighting using fixed-pipeline functionality, correct? It would be better to just disable the inbuilt OpenGL lighting functions, and pass pre-normalized values to your shaders to calculate the lighting in a game engine, wouldn't it? It wouldn't hurt to use precomputed lightmaps for static lights/geometry to speed up rendering either as far as I can tell, since dynamic shadowing techniques still leave something to be desired as far as I can tell (aliasing/speed tradeoffs) - i.e. only compute dynamic shadows for objects ingame that can be moved from their starting location, and blend other dynamic shadows cast from flashlights and whatnot on static shadows computed at compile time on static objects such as walls.
Or am I missing something fundamental here? I haven't done any other lighting apart from the fixed-functionality type before, and am trying to digest what I've read on shaders before just plunging ahead and coding stuff, only to find out later that my logic is all wonkey and that I have to rewrite half my engine ;)

This topic is closed to new replies.

Advertisement