Sign in to follow this  
redeemer90

Doom3 lighting - Any ideas??

Recommended Posts

Hello, I know this topic has been dicussed to death, but I must ask, how does Doom3 do it's lighting. If it was just (diffuse * bump ) + specular I guess I would have figured it out, but to study it further, I built a simple box room in doom edit with 1 light in it. The light is placed almost at the center of the room, so it affects all vertices equally. Now take a look at this screenshot http://img399.imageshack.us/img399/795/doom3lighting1yk.jpg It shows that the brightness of the light increases at the center of the face, where there are no vertices. If you calculate brightness of light only at the vertices, this is impossible. The only other method that I can think of is to calculate the brightness of the light at every pixel, which would not work out in real time. Not on my radeon 8500 which does not have a reverse square root instruction at the fragment program/pixel shader level (to calc distance) Anyone have any ideas as to how this is done ??

Share this post


Link to post
Share on other sites
Quote:
The only other method that I can think of is to calculate the brightness of the light at every pixel, which would not work out in real time


Your graphics card is faster than you think. The lighting calculation for diffuse lighting isn't that complex, really:

(N dot L) * 1/pow(Distance, 2) * LightColour * Albedo

(N is the normal of the surface/pixel, L is the normalized light to point vector, and Distance is the length of L when unnormalized)

What do you need a "reverse square root"* instruction for?


*what IS a reverse square root?!

Share this post


Link to post
Share on other sites
"reverse square root" -> Sorry I meant inverve square root (used for finding distance). But if you are using pow(Distance, 2), we do not need this!

(N dot L) * 1/pow(Distance, 2) * LightColour * Albedo => Yes, this should be possible, but then shouldn't 'pow(Distance, 2)' be calculated at every pixel.

Are you suggesting that they pass the light vector unormalized from the vertex shader to the pixel shader, then use this to calc 'pow(Distance, 2)'? If this case, one more texture stage will get used becuase the Radeon 8500 cannot normalize the light vec at the PS level, so they'll have to use one tex stage for passing the unnormalized light vec and another for the normalized one. Hmmm, I should give this a try.

BTW, what's 'Albedo' in your equation above?

Thanks,

- Sid

Share this post


Link to post
Share on other sites
I think he's refering to diffuse reflectivity, this would be the percentage of light that bounces off the surface given incident light ie energyOut/EnergyIn
this equation is evaulated at each wavelenght, so you have a different value for red/green/blue ie (1,0,0) would be a perfectly reflective red diffuse surface. the term albedo represents the relative amount of scattering to absorption in a praticipating medium, and is not used in the proper context here.

Tim

Share this post


Link to post
Share on other sites
Quote:
"reverse square root" -> Sorry I meant inverve square root (used for finding distance). But if you are using pow(Distance, 2), we do not need this!

(N dot L) * 1/pow(Distance, 2) * LightColour * Albedo => Yes, this should be possible, but then shouldn't 'pow(Distance, 2)' be calculated at every pixel.

Are you suggesting that they pass the light vector unormalized from the vertex shader to the pixel shader, then use this to calc 'pow(Distance, 2)'? If this case, one more texture stage will get used becuase the Radeon 8500 cannot normalize the light vec at the PS level, so they'll have to use one tex stage for passing the unnormalized light vec and another for the normalized one. Hmmm, I should give this a try.

BTW, what's 'Albedo' in your equation above?


And I believe that L is unnormalized in the vertex shader, and that a cubemap lookup is used in the pixel shader to figure out what the normalized vector should be. I'm not entirely sure how Doom3's lighting system works for codepaths that are sub-DX9 (and therefore non fragment program) however. I've heard the terms 'register combiners' and such tossed about, which I have no experience in due to my Direct3D experience.

Albedo is basically the colour of the surface.

Quote:
Didn't Doom3 use normal mapping and shadow volumes for its lighting?


Normal mapping is not a component in the lighting equation. The formula I gave above would be no different if normal mapping is applied or not, as all it does is modify the N vector prior to colour calculation.
Shadow volumes are 'seperate' from the lighting, and are only involved in figuring out occluded areas of light, and are not involved in the lighting equation, which is what redeemer is asking about.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:

Albedo is basically the colour of the surface.


That's oversimplified to the point of being wrong. Albedo is a physical measure of reflectivity (usually the average reflectivity across the visible spectrum). Snow has a high albebo. Colour is a sensation (psychological phenomenon), the perception of the wavelength of light. We perceive snow as white.

Share this post


Link to post
Share on other sites
Besides shaders, there are various extensions in OpenGL that allow per-pixel lighting, both ARB-approved and vendor-specific(like register combiners for NV only). Carmack just wrote several code paths to take advantage of various hardware generations. Depending on the hardware, the rendering takes from 1 pass per light to several passes.

Share this post


Link to post
Share on other sites
Hey guys,

Thanks a lot for your replies. I began thinking in a new direction and after a lot of googling, I found the following. I'm have not read it through, because of the limitations on google print, but I plan to get the book and read the entire thing. Atleast the thing on the 'Omni light matrix' is exactly what I am looking for :-)

http://print.google.com/print?q=%223D+Game+Engine+Programming%22+%22calculating+the+omni+light+matrix%22 (Has only 1 result as of now)

- Sid

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this