Carmack to use shadow map in the next game?

[991060]

I just watched his keynotes video, he mentioned the reason why shadow volume was chosed at the very early stage of doom3's problem: because NV20's shadow buffer is only 8bits, and this is obviously not enough to give a satisfying result. Later, he mentioned the plan to add soft shadow effect in the next game: looks like he prefered random sampling in shadow map(similar to PCF) to achieve the effect rather than jittered light source.
the videos can be found here:
http://pc.gamespy.com/pc/doom-3/539265p1.html?fromint=1

 

[991060]

He also mentioned that another reason why he stick to shadow volume NOW is that using p-buffer for the shadow map is quite slow(due to unproper design and switching between render context).

I'm not quite up-to-date regarding OGL, is there's a new render to texture standard in the upcoming OGL1.5/2.0 specification?

 

[Scali]

If shadowmaps can be made robust in realtime, like shadowvolumes are now, I think they will be the shadowing method of choice. Pixar and PDI/DreamWorks also like to use shadowmaps, if I'm not mistaken. But they can use much higher resolutions and custom sampling functions, which solve the sampling/mapping problems.
I guess we have about 5 years to solve those problems for realtime use. If the problems aren't solved, I wonder what will happen... Will scenes be designed with restrictions so shadows work only in places where shadowmaps will work properly? Or will we stick to shadowvolumes instead?

 

[[maven]]

Later, he mentioned the plan to add soft shadow effect in the next game: looks like he prefered random sampling in shadow map(similar to PCF) to achieve the effect rather than jittered light source.

IIRC, he said he used averaged jittered samples, where each sample is PCF-(f)iltered (as he's (surprise!) using Nvidia hardware).

 

[991060]

yeah, you're right, Carmack also mentioned the shadow map resolution problem. It seems he's worrying about the bad performance of using cube shadow map to represent omidirectional light sources which are quite common in games.

 

[991060]

]

Later, he mentioned the plan to add soft shadow effect in the next game: looks like he prefered random sampling in shadow map(similar to PCF) to achieve the effect rather than jittered light source.

IIRC, he said he used averaged jittered samples, where each sample is PCF-(f)iltered (as he's (surprise!) using Nvidia hardware).

Err, maybe, English isn't my native language, I could've missed some details.

 

[AlNom]

I thought he just said that he was likely to Nvidia's extensions as he's using their cards for development.

 

[pocketmoon66]

Pixar etc can use shadow maps because

a) the can afford HUGE shadow map resolutions and

b) the scenes are predefined so you can position you shadow map to
cover everything that you expect to cast a shadow in the scene.

Hard to do in a dynamic environment. Nvidia have some cool shadow mapping demos showing quiet advances techniques in their latest SDK.

 

[AlNom]

JC did say something about including 16 samples to be taken for pre rendered stuff for the engine....

Enhanced Doom 3 engine tech in movies?

 

[Reverend]

He said he had both shadow buffers and shadow volumes (working, as alluded by him) in Doom3, toggling between the two even. Woulda been great if we could get our hands on that!

Basically, he spent a whole lot of time talking about shadow qualities, shadow artifacts, his workarounds for these... wished he'd talked more about other stuff that are just as important in rendering. I found his brief talk about Willits' complaint about translucency rather nice though.

Oh wait, am I going OT?

 

[Scali]

He said he had both shadow buffers and shadow volumes (working, as alluded by him) in Doom3, toggling between the two even. Woulda been great if we could get our hands on that!

That will probably only work on certain hardware paths then. Since Doom3 uses mostly pointlights, you would need cubemaps, and my experiments on a GF2 with 8 bit cubemap shadows weren't exactly a big hit
So I suppose the NV1x path would lack the capabilities and speed to get decent shadowmaps working.

It would be interesting though if it could at least be enabled on the ARB2 path, so we can compare speed and quality.
Personally I'm not such a big fan of cubemap shadows since they are about as fillrate-intensive as stencil shadows, and you still have the sampling problems inherent with shadowmap approaches.

Edit: apparently Carmack has a slightly different approach, where he doesn't use a cubemap, but basically 6 frusta each with its own map, with easy-to-adjust resolution... I wonder how well that works.

 

[AlNom]

I just need to listen to what he said at least 10 times to make sure I ask questions that he'd want to answer!

I have the first part of that key note address (gamespy part 1) written up if you want it....

it's.... not quite grammatically correct with respect to sentences and punctuation though.

 

[Richard]

I just need to listen to what he said at least 10 times to make sure I ask questions that he'd want to answer!

I have the first part of that key note address (gamespy part 1) written up if you want it....

it's.... not quite grammatically correct with respect to sentences and punctuation though.

I'd love to see it. I don't want to download the whole thing (500mb right?)

 

[AlNom]

I'd love to see it. I don't want to download the whole thing (500mb right?)

it's about 5 pages with the font I used

email?

 

[Richard]

thx man. PM sent.

 

[KimB]

Personally I'm not such a big fan of cubemap shadows since they are about as fillrate-intensive as stencil shadows, and you still have the sampling problems inherent with shadowmap approaches.

Well, as for how fillrate-intensive shadow maps are, well, they have completely different fillrate characteristics, and the cubemap will be vastly more efficient if the shadow hulls are large compared to the objects. The shadow volumes, of course, will be much more efficient if the objects are large compared to the shadow hulls.

Regardless, in the long term, it's not the fillrate requirements, but the cost of generating the shadow hulls that eliminates shadow volumes as being the most efficient way to calculate shadows.

 

[Scali]

Regardless, in the long term, it's not the fillrate requirements, but the cost of generating the shadow hulls that eliminates shadow volumes as being the most efficient way to calculate shadows.

What do you mean with shadow hulls? The volumes themselves (perhaps the uncapped version?)?
Since I use a GPU-based approach, the generation is basically 'free' (the vertexshader overhead is well-covered by the rasterizing overhead).

If this is about Doom3 using a CPU-based approach, I am getting really tired of that. Carmack may have chosen that approach, but there are people who haven't, and don't have the CPU-overhead that is associated with Carmack's approach.

 

[V3]

So what kind of improvement in hardware should we get to improve the useability and quality of shadow buffer ?

And what kind of improvement can we expect from GPU makers (or nvidia), now that Carmack seems to side with shadow buffer ?

 

[psurge]

Scali - (just curious) have you explored the tradeoffs? A CPU based approach should significantly lower the rasterization/fill-rate
requirements...

Regards,
Serge

 

[Humus]

What do you mean with shadow hulls? The volumes themselves (perhaps the uncapped version?)?
Since I use a GPU-based approach, the generation is basically 'free' (the vertexshader overhead is well-covered by the rasterizing overhead).

If this is about Doom3 using a CPU-based approach, I am getting really tired of that. Carmack may have chosen that approach, but there are people who haven't, and don't have the CPU-overhead that is associated with Carmack's approach.

I think he's talking about extracting the silhuette from the source model, which must be done by the CPU no matter what. This means that you must keep to low-res models to be able to do it in real-time.