Questions about how Doom 3 handles shadows

1) Why wasn't EVERY surface in the game shadowed? Several areas in the game lack shadows, and at no point do you see shadows projected from the player or weapon pickups. I assume this was done to keep the framerate decent.

2) How do multiple light sources affect shadows? A few times in the game, I saw two shadows being projected at once, but if there are a large number of light sources in a given area, one should logically see a large number of shadows of varying luminance values. I assume there's a limit to how many shadows can be projected from a given surface.

3) There are a few points in the game that feature shadows with penumbras. Is there some sort of option in the editor that determines which shadows are stencil shaded, and which ones are shadow maps? Could the entire game's geometry potentially use the shadow map method?

4) I understand that stencil shadowing was a computationally efficient way of producing semi-realistic shadows, but I've noticed that some of the shadows aren't pitch black. What accounts for this and why couldn't all of the shadows be of various luminance values?

5) If you look at the fourth screenshot of in the "Doom 3: Phobos" thread (http://www.doomworld.com/vb/doom-3-general/63061-doom-3-phobos/), you can clearly see the player holding a shotgun, which has been colored blue from the lighting. However, the darkest areas are no darker than the blue of the light; is the engine not capable of producing the darker and ultimately black shades one would expect to see in such lighting?

Share this post


Link to post

I'm not sure if anybody but Carmack himself could answer these. The fact you know to ask them in the first place means you already know more about it than me, at least >__>

Share this post


Link to post

1) Like you guessed, it's a performance issue. Some areas are given lights that do not cast shadows. Some materials are also set to not cast shadows.

2) The shadows depend on several things. Is the material a shadow caster? Is the light? Is the light big enough to contain both the caster and the geometry to cast against? Some of the lights are undoubtedly set to not cast shadows. Performance is heavily dependent on how much shadow-geometry (in reality it's light geometry, the shadows are what does not get rendered) there is in a scene.

3) That is whenever a texture is applied to the light. It doesn't cast soft shadows, it just projects a picture onto the geometry. Usually to simulate light coming from behind grates, fans or flickering light.

4) Whenever a shadow isn't pitch black, it's because another light is hitting the surface. This would usually be to avoid having pitch black corners, so you put in a fill-light with a low light level and disable shadows on it.

5) The engine is very capable of producing dark or black shades. Getting it to not do this is the hard part. Pitch black is the default :)

Share this post


Link to post

I'll add a few cents.

1) Seeing your own shadow is pretty cool... until you look down.

3) Some shadows are made with decals. They're usually being "cast" by hoses hanging in front of walls, I don't remember any other examples.

5) Fog.

Share this post


Link to post

i looked at the light related source code at multiple times to figure out a way to "force expand it", so i will take a throw at this.
do not take my answers as an absolute truth, i did not look at everything light related and i might be wrong at some points.

1) the engine seems to load the map in an pitch black unlit condition. then it starts to add the lights, and calculate the rendering list for them. the pitch black areas in the map never seems to be touched by a light. then the source code contains calculations which check if the model surfaces are defined as being capable of receiving or casting shadows. many of those routines are programmed in a way to skip unnecessary calculations.


2) the engine seems to calculate shadows based on the closest light touching it. but this might be something i need to read again in the code to fully understand this system, but at the moment i read the code as ; " shader / object has already been added to the shadowcaster list, will not be added multiple times"

3) the engine its code for stencil shadows is complex, my best bet on remembering it is that it is somewhat hardcoded.

4) for this i need to read the code in a way more efficient manner.

5) one light is orange of nature, and casts orange lighting on its surrounding, and i suspect the strong blue light is casting an additive hue over the surrounding area or there is some kind of fog changing the way the render is made, cancelling out the pitch black.

Share this post


Link to post

Thanks for the replies, this has been really fascinating. One quip: Firefish, I don't quite understand your answer to question 3.

Share this post


Link to post

part 3 is all about the stencil shadows, which is a complex piece of code that i did not read enough to understand it 'better'.

Share this post


Link to post

Well, the answer is quite simple and doesn't require looking into the source code: there aren't any "true" soft shadows in Doom 3.

Share this post


Link to post
Da Werecat said:

Well, the answer is quite simple and doesn't require looking into the source code: there aren't any "true" soft shadows in Doom 3.


Pretty much. Any of the soft looking shadows are in reality a grayscale texture that ends up being a value from 0.0 to 1.0 that they in the pixelshader use to multiply the resulting color of all the other operations.

Share this post


Link to post

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