Lighting

[Chi Haotian]

Does D3 engine take into account the dispersion of light when it does lighting/shadow-casting? Because notmally, the further an object is from the light source (or the light source and the object -- from the surface), the more the cast shadow will be blurred. I don't remember if D3 had this effect, but TDS sure didn't -- the shadows in TDS were always sharp no matter what the distance was, and it didn't look good despite even the fancy dynamic lighting. Will this be addressed in TDM?

[Gildoran]

No, that's not technically possible with stencil shadows. The stencil buffer is used to partition the screen in areas that are in light and areas that are in shadow. Stencil shadows are an efficient way of doing things, but they don't allow for "intensity" of shadows.

 

Mappers can sometimes fake soft shadows a little bit with carefully designed light fall-offs and filter blend lights, but in general soft shadows will probably never be a part of TDM.

[SneaksieDave]

...Until Doom3 code release! [hopeful thinking]

[Gildoran]

Adding soft-shadows would probably require a complete overhaul of the core rendering engine to do, at which point we might as well write everything from scratch and not use the D3 engine.

[SneaksieDave]

I'm sure modifying a lighting system to support soft shadowing - especially on future hardware - would be far easier than writing an entire engine. I figure if they can get realtime light and stencil shadows in Quake 1 (Tenebrae), why not soft shadows in Doom3 some day?

[Chi Haotian]

So, if Doom 3 engine code is released, it would take its re-writing to get soft shadowing? I never programmed an engine, so I have little idea of how this works, but wouldn't making that change mean modifying just that module that deals with lighting, and not the entire engine?

Edited February 1, 2007 by Chi Haotian

[Ishtvan]

The module that deals with lighting things so that you can see them is the render engine.

[Nyarlathotep]

You can already replace the render engine. The advantage of having the source code is that you don't have throw the module away to rewrite it. Comparatively speaking, adding things like shadow-mapping and hdr are simple modifications; you only have to add or replace the related code, and relatively separate components like the visportalling system can remain virtually untouched. I seem to recall discussions about there being an alternate render path included in Doom 3, that did shadow-mapping and hdr, but none of the relevant code remained (having been stripped down before shipment). The issue was that there wasn't any useful way to access the components of the old render path to construct a new path, or substitute new components without writing an entire render path.

[Crispy]

You can already replace the render engine.

Only if you want to rewrite most of the rest of Doom 3 as well. Any volunteers?

[sparhawk]

I'm sure modifying a lighting system to support soft shadowing - especially on future hardware - would be far easier than writing an entire engine.

 

I wouldn't bet on it. Integrating some new concept into existing software, that it was not designed to do, is usually a VERY big task. That's why companies usually write new engines instead of upgrading the old engines, when to much new technology is coming up.

[Domarius]

A good analogy is trying to install a turbo charger on... some old car. I don't know my cars, but you get the idea. Would be much easier to install a turbo charger on a newer car that supports the current technologies. Or better yet, build a car that has the abilities of a turbo charger integrated more efficiently.

[bob_arctor]

Meh, soft shadowing would kill my PC anyhow.

 

Who needs it?

 

We made do with TII for years.

[SneaksieDave]

I maintain that it could and probably will be done (not necessarily by the TDM team). Unreal 3 comes out, soft shadowing goodness, Crysis comes out with more of the same, and then the Doom3 source is released. You honestly don't think someone wanting to make a name for themselves isn't going to get right down to work on the task? Okay...

 

Even if it can't be done in a formal, 'correct' sense, I'm sure there are tons of hacks to approximate it (hell you can even fake it in TDS if you accept 2 FPS). Open box, think outside of it.

[sparhawk]

I think I know a way how to do it.

[Nyarlathotep]

Do tell! Without implementing a significantly more advanced form of lighting/shadowing, e.g., shadow-mapping, spherical harmonics, dynamic ambient occlusion, how would you implement soft shadows? The only ways I can think of are jittering multiple point sources and blending the results, or attempting some way of doing penumbra-umbra approximation. What are you thinking of?

 

Only if you want to rewrite most of the rest of Doom 3 as well. Any volunteers?

I'm sorry, was I not clear enough stating that in my post? The SDK code, i.e., the game code, and depending on how you did it, some of the (very small portion) of D3E's engine would remain. The rest would be flushed away. I don't know what proportion the render engine represents, but I do know that it is a very significant portion. People are too quick to assume that that which is wholly impractical is impossible.

[Crispy]

I'm sorry, was I not clear enough stating that in my post? The SDK code, i.e., the game code, and depending on how you did it, some of the (very small portion) of D3E's engine would remain.

Ah, but you said that we could already do it. Right now, we only have the SDK; so you'd have to rewrite the entire engine, not just the rendering code. I don't see how you could save parts of the engine, unless you were to disassemble the executable and include large chunks of the resulting assembly code in your rewrite. (Which almost certainly violates the EULA, and would be a lot of tedious work besides.)

 

When D3 is GPLed, then yes; rewriting the renderer will be a realistic proposition, if somebody wants to take the time.

[Nyarlathotep]

I never said it was realistic, just possible. I mentioned in my first post about a way it might be possible to override the renderer separately, but I'm a bit fuzzy on the details (not that the original thread wasn't vague to begin with).

[Gildoran]

Do tell! Without implementing a significantly more advanced form of lighting/shadowing, e.g., shadow-mapping, spherical harmonics, dynamic ambient occlusion, how would you implement soft shadows? The only ways I can think of are jittering multiple point sources and blending the results, or attempting some way of doing penumbra-umbra approximation. What are you thinking of?

Using shadow buffers... For example, you start off a scene shadow buffer at white. Then for each object, you project it into an image from the perspective of the light, where the object is black and everything else is white. Then you could apply some kind of blur based on the depth buffer of that image to obtain distance-based blurring. Then you could project that image onto the scene the way D3 projects lights, but write it to the shadow buffer using modulation. Repeat this for each object, and when you're done you can render the lighting taking into account the shadow buffer.

 

However, there are some tricky problems, such as what to do if an object encompasses an FoV of more than 180 degrees for a light... (for example, if you place a light in a bird cage) I guess you'd have to project it onto multiple textures, like a cube map of some sort. But then there'd be issues with getting the blurring to cross the boundaries of the multiple projections, which seems hard to do. So you'd probably end up with graphical artifacts where the boundaries of the shadows projection images meet.

 

One of the things I really like about the D3 engine is how it gets direct lighting and shadows "correct" for opaque objects. In TDS, it was easy to get glitches if you didn't set the shadow projection distance large enough, etc. In D3, that sort of stuff doesn't happen. I'm not keen on introducing features that would result in graphical artifacts.

[Crispy]

I mentioned in my first post about a way it might be possible to override the renderer separately, but I'm a bit fuzzy on the details (not that the original thread wasn't vague to begin with).

Do you mean a different thread? I can't find the post you mean.

[Domarius]

Even if it can't be done in a formal, 'correct' sense, I'm sure there are tons of hacks to approximate it (hell you can even fake it in TDS if you accept 2 FPS). Open box, think outside of it.

Video games are nothing BUT a collection of faking / approximation / smoke & mirrors. "Thinking outside the box" is pretty much a pre-requisit for making a video game.

 

Even the most awesome physics you've ever seen in a game, is actually called "ridgid body physics", where every object is assumed to be perfectly solid, and never bend or compress in any way, and hence, all impacts are "instantaneous". That is, as soon as the collision happens, the result happens instantly, there is no period of compression or flexing before bouncing back. And this "short cut" introduces quirks in certain situations, which you have to cover up with more "faking" etc.

[Nyarlathotep]

Using shadow buffers...

Shadow buffer is generally used to describe hardware accelerated shadow mapping. I had been wondering if there was a (relatively) cheap way to get soft stencil shadows.

 

I'd also like to point out that there a number of optimizations that can be performed, such as doing it per light rather than per object, and warping the shadow texture based on the perspective of the both the camera and the light. Also, it meshes quite nicely with dynamic ambient occlusion (as presented by Nvidia), allowing two-pass indirect lighting (note: two-pass for each bounce).

 

Do you mean a different thread? I can't find the post you mean.

Actually, it was on a different forum, Doom3 World if I remember correctly. Someone had asked about adding true hdr, only to be shot down by the fact that Doom3's engine is relatively fixed.

[Ishtvan]

Been trying to resist saying this but can't... resist... any longer... that's diffraction not dispersion! Dispersion usually refers to wavelength-dependent "speed" in a medium.

[Gildoran]

Shadow buffer is generally used to describe hardware accelerated shadow mapping.

With what I was describing, you could use the hardware to speed it up significantly. For example, you would be using the graphics card to render the shadow images.

 

soft stencil shadows

I'm pretty sure that's an oxymoron. The whole way stencil shadows work is that each pixel is in shadow or not. There's no notion of partially in shadow. Also, since it's each pixel, not texel, I'd be skeptical that blurring would work well.

 

I'd also like to point out that there a number of optimizations that can be performed, such as doing it per light rather than per object, and warping the shadow texture based on the perspective of the both the camera and the light.

What I was describing was pretty much per light. The pseudo-code would be:

foreach light
{
clear the scene shadow image to white
foreach object in the light
{
	clear the object shadow image to white
	render the object from the perspective of the light to the object shadow image, drawing it in black
	optionally apply blurring
	project the object shadow image onto the scene shadow image, drawing it with modulation
}
render the light additively, modulating it by the scene shadow image
}

Did you have something else in mind?

 

Also, it meshes quite nicely with dynamic ambient occlusion (as presented by Nvidia), allowing two-pass indirect lighting (note: two-pass for each bounce).

Actually, it was on a different forum, Doom3 World if I remember correctly. Someone had asked about adding true hdr, only to be shot down by the fact that Doom3's engine is relatively fixed.

Being able to do indirect lighting in two passes per bounce sounds too good to be true... I guess I should go read about it.

 

@Ishtvan: Dispersion is what usually limits the length of fiber-optic cables, right?

[Ishtvan]

@Ishtvan: Dispersion is what usually limits the length of fiber-optic cables, right?

Pretty much, yeah, but I think the whole story is that it's a combination of dispersion and nonlinear effects that limit fiber length.

 

Dispersion

When you transmit a pulse with a finite width in time, it has some finite width in the frequency domain since that's a Fourier transform pair. When you try to propagate that pulse through the fiber, the different frequency components have slightly different speeds in the fiber (dispersion), and your pulse ends up spreading out or contracting in time (you can engineer whether it will spread out or contract, more on that later). If it spreads out too much, and you're trying to send a pulse train, each pulse in the train spreads out until more and more until it spreads into the time slots for the adjacent pulses, then you get errors.

 

Now, it turns out that you can engineer a fiber with zero dispersion or flat dispersion. That solves all your problems right? Wrong.

 

Nonlinear Effects

Simplistically, nonlinear effects occur when the light pulse modulates the refractive index of the medium (i.e., the intensity of the light in the medium changes how fast the light travels in that medium).

 

When there's zero dispersion, nonlinear effects actually get a lot worse. A nonlinear effect (like self-phase modulation) takes some of the energy at one frequency and couples it into another frequency. If there's no dispersion, both these frequencies travel along at the same speed, so they're phase matched and the coupling efficiency from the frequency you start with to some other undesired frequency is very high. This is bad, because it changes your pulse spectrally and hence in time.

 

Also, if you're trying to send multiple wavelengths over a single fiber (WDM), a nonlinear process causes cross-talk between the frequency channels, and if you have zero dispersion over your wavelength range, again you phase-match all the frequencies and make the nonlinear coupling much more efficient, making the cross-talk much worse.

 

Practical Solution

In practice, one usually alternates long sections of fiber with small negative dispersion (pulse spreads out in time), with short sections of fiber with large positive dispersion (compress the pulse in time).

 

For more information, see Govind P. Agrawal, Fiber-Optic Communications Systems.

[Nyarlathotep]

Been trying to resist saying this but can't... resist... any longer... that's diffraction not dispersion! Dispersion usually refers to wavelength-dependent "speed" in a medium.

Actually, no. Diffraction has minimal to no effect on shadow formation at human scales and frequencies. The lack of a penumbra in modern direct lighting has everything to do with the inadequate approximation of area lights by point sources.

 

I'm pretty sure that's an oxymoron. The whole way stencil shadows work is that each pixel is in shadow or not. There's no notion of partially in shadow. Also, since it's each pixel, not texel, I'd be skeptical that blurring would work well.

There's more than one way emulate a penumbra from a hard light source, and using multiple lights is only one.

 

*Happy funtime code!*

Did you have something else in mind?

Possibly, but my limited knowledge of graphics hardware prevents me from seeing if your algorithm is different than what mine actually would wind being. (it is different than I intended). Specifically, you still have a foreach object inside, but I couldn't state for a fact whether this is necessary, rather than simply pulling the entire scene from the depth buffer in one go.

 

Being able to do indirect lighting in two passes per bounce sounds too good to be true... I guess I should go read about it.

Yeah, it does, doesn't it? Honestly though, Geomerics claim of "infinite bounce" real time GI is a lot wilder. Ambient occlusion has some pretty serious limitations, but it's a lot better than other real time GI approximations out there--especially since it can be implemented with no precalculations.

 

Check it out: Nvidia's version of Ambient Occlusion

 

NB: There are some optimizations out there that do ambient occlusion in one pass by precalculating it as much as possible, but they tend to require a rather large file.