Doom 3, lighting/shadows, and BSPs

OpenGL OpenGL: Advanced Coding
41

Ron, if I didn’t see it as a cute joke, it was because it was surrounded with other material “%(&% please please please” and followed by “O” “I”. If you try to ridicule me and follow it up with a smiley it doesn’t make it OK. Let’s just put it behind us, I know there are lot’s of smart people posting on this thread (you are definitely one of them) we can have fun discussing some phenominal graphics work without bickering. I just don’t see is as such a big deal if I say that there are some light maps / soft shadow effects in a screenshot.

I don’t think I was presenting opinion as fact, and that should be self evident now with the screenshot and the video if you look at it.

One of the interesting aspects is that we can discuss Doom 3 without being constrained by Carmack’s design decisions. Even if Carmack doesn’t cache near occulters to a projective shadow texture to reduce stencil depth complexity (and he might), we should be able to discuss that option. Graphics won’t stand still with the Doom 3 engine.

[This message has been edited by dorbie (edited 05-24-2002).]

42

Dorbie, (and others)

John has repeatedly said that his lights are projected, that his models are bumped mapped and specular, and that “everything” has shadow volumes and gets lit the same way.

Briefly, this means that he’s probably first “painting light” in additive mode, and then modulating in color mapping. This is much more similar to how light actually works in the real world than any previous real-time method!

When you’re “painting light” it’s easy to do that with a texture projected from the light (maybe even a cube map) to simulate things like spot lights, rotating colored warning lights, fire grates, or what have you.

A rotating fan may be done with a projected shadow, or it may be done with an actual shadow volume. However, if there’s a soft “shadow” then that’s most probably a property of the light being painted, not of the shadow volume.

Now, what’s a good name for these projected light textures? “dynamic light map” seems a little complex, and somewhat confusing compared to regular light maps. How about “projected light texture”? :slight_smile:

43

Painting light is another way of saying light map. OK so it is projected, I said this early on and observed multiple overlapping independently modulated light maps. Maybe “shadow texture” is appropriate, see the Siggraph technical note I referenced. To set this up as a big adversarial thing is counter productive. Everybody ends up beating their chest and refusing to acknowledge common ground. I do think many of us have a pretty good idea of how this lighting works, and the details where we don’t agree could be fertile ground for discussion.

You do make a good point that much of the disagreement may be over semantics and preconceived notions of what a light map is and how it is generated and applied.

BTW JWATTE, Performer uses coloured additive projective texture lights for it’s spotlights. It didn’t have fancy fragment effects and occulters but it did paint the spotlight effects that way to the framebuffer.

[This message has been edited by dorbie (edited 05-24-2002).]

44

Did not mean to start a war by picking a side I see what you mean now dorbie. And I think jwatte as it right.

I am sure they build their lights a way similar to this.

The artists creates a model of the light and textures it. Then you simply create a texture of the light surface. You then use this texture as your projected light. You need to create a texture of the light, because the light could be of any shape.

This obviously will give nice smooth “shadows” if light is textured with grates. But this is simply implicit to the texture filtering and was not originaly intended. That is what I meant with there are no soft shadows.
So I guess everybody is just arguing over the same thing.

45

Gorg,

I don’t think you started anything, I too agree that this is likely, it is exactly what I described in post 21 in this thread before I was char broiled :-). I later realized it would be similar in many ways to the Siggraph technical note I mentioned subsequently. I’ve tried to be pragmatic about interpreting what I see. There may be several shadow layers as per the Siggraph sketch which modulate (or simply replace) each other and are applied depending on location inside the shadow beam tree, I mentioned this in an earlier post but it probably got lost in the noise for most readers.

As for soft shadows, I wouldn’t rule it out this may include some filtering or multipass sampling to the “shadow texture” especially for static geometry. At the very least some antialiasing would be desirable to avoid horrible shadow aliasing, and when you then project the texture the penumbra (or at least the antialiased shadow edges) automatically increases correctly (approximately) in scale.

This speculation may be incorrect but one thing is certain, it is wrong to make sweeping generalizations simply because the lighting model has been called unified. Carmack has never said there are no light maps or shadow textures in his approach. He has only said his approach is a general and consistent solution. How he arrives at that could easily include shadow textures.

Despite accusations about light maps and a misleading discussion summary that tries to present me as the idiot, I mentioned this projective shadow method as an option immediately BEFORE I was ridiculed.

[This message has been edited by dorbie (edited 05-24-2002).]

46

I think dorbie may be right that the projected “shadow” textures could be automatically generated ( pre-generated on load time seems more likely but anything is possible ). I like to think of this as a “canned” light source. For example, a simple lamp shade could be made to project a soft’ish shadow, it would be wasteful to use shadow volumes for this ( and it wouldn’t look as good ). Anyway, I’ve used this technique with cubemaps so it’s definitely a possibility.

Also, I think some lights are handled in clusters ( with a single reference point for shadow volumes ).

47

I agree PH, no need to do more work than you have to.

48

projected shadows textures aint hard (and are cheaper than u think my vanta had no real problems dealing with them (except the extra verts of course but on a hrdware t+l card this aint an issue))
ive been using them for about 2 years to do soft shadows of moving objects/lights http://uk.geocities.com/sloppyturds/gotterdammerung.html
the problems with them are when the light/object become very close to each other.

cause this is has gotten a bit to friendly i’ll throw in my desenting voice unified for me means every polygon goes through the same path, im not ‘quibling’ (is that the right word) with words but unified aint
all polys
{
use_projected_shadow_texture
else
use_stencil_volume
}

49

Originally posted by dorbie:
Painting light is another way of saying light map.

I dont think so. Maybe it is a light in the sense that it is a texture-MAP of LIGHT information, but the traditional idea of lightmaps has always been a texture map that has all details of the scene lighting baked into it and is simply modulated into the base texture. What I think this looks more likely to be is a sort-of-filter (jwatte: I like the term “projected light texture”) for the perpixel lighting model. As I interpret what is being done, I suspect this can all be done right along with the bump mapping, diffues attenuation, etc…stuff that isnt dont with traditional lightmaps.

As for soft shadow (jittered volumes, etc) I highly suspect that is not done simply because of the fill rate required. Narrowing it down to a small number of tris is pretty irrelivant, because the typical limitation with shadow volumes is NOT about how many tris you have, but on how much fill rate you consume. Because the way the shadow volumes are projected out into the distance, they tend to consume a LOT of fill rate. Even a simple 3 sided shadow volume can take up tremendous fill rate. Another reason I dont believe this is a jittered volume is because even jittered volumes dont produce that nice of a soft edge with out a few dozen (or more) jitterings (is that a word???), which would be a fill-rate-hungry-frame-rate-killer.

Carmack has never said there are no light maps or shadow textures in his approach

Actually, Im almost 100% sure he said this at one point. I’ll have to go try to find out where he said it (although if you take a look through the archives here, you will see what happened the last time I was “almost 100% sure” of something John Carmack said )

As far as what gets baked into the projected light texture, remember that when this light is projected out, the object casting this shadow is also going to incorrectly appear shadowed. For this reason, it could only realisticly be done for object close to the light (as dorbie said) or objects that the camera will otherwise never see the back-unlighted side of. Also, doing this for moving lights makes it even trickier becuase then its harder to ensure that the player doesnt see the backside (unless you really dont even care if the viewer sees the errors)

50

dorbi. you just call everything lightmap, don’t you? please refer to the standart-usage of these names.
[bitching]when you use shadow-volumes, you are in fact realtime generating a lightmap for sharp lightsources in screen-space, and the resulting texture, wich fits perpixel to the screen is then logically as well a lightmap[/bitching]

lightmaps are normally precalculated textures wich store lighting information, they have been precalculated, and have defined constant texture-coordinates.

shadowmaps are depthmaps rendered from the camera point of view, then doing a z-test against the pixel-distance from the lightsource to compare if in shadow or not, or they draw an indexmap and compare against the index again. this is normally a projected texture, or can be a cubemap as well.

the painted lights are on the other hand independend of geometrie, but simply an extension to spotlights, meaning they have a map, wich stores for each direction what the color of the lightsource is. this can simply result in a spotlight, or a beacon, a disco-light or whatever, but has nothing to do with shadowing and is independend from geometry. in this sence, its part of the lighting-equation of the local surface element, like the diffuse term, ambient term or specular term are in the phong-equation (or blinn one, or brdfs or what ever).

don’t just mix all the stuff up to do like you’re right with your wrong statement.

carmack said he uses shadowvolumes to determine the shadowing-term of each pixel. no more, no less. if this is not the case, he is a liar.

this is independend on how he does the lighting itself. there he uses bumpmaps with some specular term, and depending on material environmental maps as well, possibly env-bumps for waterplanes even, and possibly even some brdf-functions somewhere. i don’t know much about how he does calculate the lighting, but it looks like some sweet approximation/extensation of the standart blinn/phong model.

51

ok, i just THINK , that the option he is not using a regular radial attanuation map was overlooked. i think that by using 3d textures instead of 2*2D textures gives u the option to encode lots of lighting effects into the attanuation map beyond spotlights. the only problem i see with this problem is that it will use too much video memory if every light will have a different attan map, but this can be optimized. what do you think?

52

>>carmack said he uses shadowvolumes to determine the shadowing-term of each pixel. no more, no less. if this is not the case, he is a liar<<

can u show link us to the quote thanks, cause shadowvolumes personally can mean ‘projected shadow textures’ cause u need to cast them in the ‘shadowvolume’ as well as the ‘stenciled shadow volumes’
maybe we need a glossary so we can look up the standard terms so no confusion results

but like i said project shadow textures have problems (which can be worked around but do get expensive)

after another look at the screenshots it looks like 2 techniques stencil shadow volumes + projected shadow textures which like i said before aint IMHO unified, to reiterate what i said 6months - 1 year ago i believe carmack aint using either of these methods then again i might just me RAMBLINGKT

btw LordKronos i believe noone was suggesting doing jittering of the shadow volumes were they?

53

I don’t think 3d textures is an option since they still want it to be able to run on “low-end” 3d cards like geforce2.

Also from looking at the screen JC is before in the doom legacy movie (while working on the doom3 shadow code!) I guess they are using stencil with scissor testing to speed things up. And an ambient light term!
And I dont see any c++ seems plain typedefs to me
(unless is is a mockup to mislead us mere mortals of course)
If you want to look at fuzzy code you can find some shots here http://users.pandora.be/hollemeersch/blackrose/images/shot1.jpg http://users.pandora.be/hollemeersch/blackrose/images/shot2.jpg

Charles

(ps:is this legal??)

[This message has been edited by Pentagram (edited 05-25-2002).]

54

Originally posted by zed:
can u show link us to the quote thanks, cause shadowvolumes personally can mean ‘projected shadow textures’ cause u need to cast them in the ‘shadowvolume’ as well as the ‘stenciled shadow volumes’
maybe we need a glossary so we can look up the standard terms so no confusion results

well, if i find it again, i’ll show it
about the glossary:
“projected shadow textures” are called shadowmaps. go to the nvidia dev page and you’ll see it.

about the carmack and usage of STENCIL shadow volumes… i just say one thing: carmacks reverse.
i say another thing: GL_NV_depth_clamp
this extension came right after carmack stated this would help to get with its own developed reverse to perfect shadowvolumes

55

Hi,

I think that using an absolutley unified lighting model can not produce good results. The doom 3 movie is full with quite complex scenes, with a complex shadow being cast on them. In most of the scenes there is a shadow of some kind of bars or shuttres, being cast on the geometry. It is highly unreasonable that those bars/shutters are real geometry.

I believe it could be done with some kind of projected texture, or a 3d texture as suggested. That adds to the realism of the scene, in the cost of a bit of work from the artist/designer. A light map, as far as I concerned, is not an option, if the compiling time (of the level) is very short (is it?).

I think that using only stencil shadows can look too sharp and not realistic in many cases, and I am sure that there are some “soft shadows” of some kind in doom 3.

Quaternion.

[This message has been edited by Quaternion (edited 05-25-2002).]

56

>>“projected shadow textures” are called shadowmaps<<

we definitly need a glossary

projected shadow textures" are NOT shadowmaps, with shadowmaps u cant really do softshadows easily

57

Originally posted by zed:
[b]>>“projected shadow textures” are called shadowmaps<<

we definitly need a glossary

projected shadow textures" are NOT shadowmaps, with shadowmaps u cant really do softshadows easily[/b]

okay sorry, i understood projected shadow textures wrong…

projected shadow textures i never count to shadow-methods at all, cause they don’t store geometrical information at all. its just a texture with bright and dark parts projected onto the scene and modulated (and it looks exactly like this in the videos). that is just a texture, nothing more. at least for me…

let the war continue…

58

Originally posted by zed:
btw LordKronos i believe noone was suggesting doing jittering of the shadow volumes were they?

Shag was discussing the screenshot and said “it wouldn’t be too hard to create soft shadows using some jittering method”.

59

Originally posted by zed:
projected shadow textures" are NOT shadowmaps, with shadowmaps u cant really do softshadows easily

Yes, it is a bit confusing. Projected shadow textures (if thats the correct term) basicly just modulate the light level. This can create soft shadows. Unfortunately it is also depth unaware and (if projected onto the object casting the shadow) will actually incorrectly shadow the casting object.

Shadow maps (or should it be a shadow depth map?) stores the distance at every texel from the light to the nearest object. For every pixel rendered, the distance of the pixel from the light sorce is compared to the depth stored in the shadow map. IF the distance is greater, it gets shadowed. This has the advantage that it can correctly self shadow the object, but it does not generate soft edges.

60

Dorbie> There may be several shadow layers
Dorbie> as per the Siggraph sketch which
Dorbie> modulate (or simply replace) each other

I think this is incorrect. I don’t think there’s any modulation nor replacement. I think the scene starts out as all shadowed, and all the light that’s painted is ADDED, not modulated. I think the shadow volumes serve as gates for whether the light gets added or not, but there’s no modulation going on. Unless you want to be really mis-leading and calling additive blending for “modulation” which would just be plain wrong, again IMHO.

Thus, calling the projected light textures “shadow maps” is, to me, misleading enough to be called inaccurate. And calling them light maps is also misleading because that term is already used for another kind of map, which gets modulated instead of added.

When John Carmack described his engine in one sentence, he said that “once we decided that all lights were projected, that everything cast a shadow volume, and everything was specular bump mapped, everything followed neatly from that”. I think this explains the model quite neatly, and there’s no shadow maps needed or implied by this approach.

Anyway, so while this discussion may be somewhat about just finding common words for the same things, it seems that the words that have been used (mostly the ones including the stems “shadow” or “modulate”) are misleading enough that using them leads to more confusion than clarity.

“Projected light textures” for the future!

EDIT: Of course, there has to be at least one modulation pass, which happens when you have decided on the lighting for a specific frame buffer pixel, and then go to apply the “base color” map/shader to the pixel. However, I don’t believe this form of modulation should be mentioned while discussing the lighting solution, as it’s not part of the lighting calculation, but instead of tinting happening after “full albedo” lighting and shadow is already calculated.

[This message has been edited by jwatte (edited 05-25-2002).]