r_showShadows + shadow volumes

[OrbWeaver]

Exactly. And the GPU operation in shadow.vp is indeed skipped for dmapped shadow volumes, but I'm thinking that that doesn't matter because it's a trivial operation, vanishingly insignificant compared with the effort of rasterizing the shadow volumes into the stencil buffer.

 

Right, and now we have unified shaders, whereas the hardware at the time had many more pixel shaders than vertex shaders (e.g. 16 pixel shaders but only 6 vertex shaders), so it would have made sense to limit the vertex shader operation then but maybe not so much now.

 

The bit that won't be trivial on the CPU is sillhouette detection and the constant loading of sillhouette indexes into the vbo. But if we can move that to shadow.vp too... tris whose verts don't get moved and that leave a degenerate edge won't get rasterized will they?

 

An alternative to moving this onto the GPU might be to try and improve CPU-level parallelism, since at the very least I would expect it to be possible to calculate silhouettes of different objects independently, and as I understand it the current engine code is heavily dependent on a single core.

 

maybe moving lights weren't a factor in the original design.

 

That seems unlikely to me, since dynamic lighting was very much a showcase feature for the Doom 3 engine when it came out.

[motorsep]

Cool. We can test it without a special engine build. Dmapping with shadowopt 0 will turn off dmapped shadows completely, and there's another option: you can make the game abandon its dmapped shadows and to start using turbo shadows by using a brief script to move all light origins a tiny amount. That will invalidate all the dmapped shadow volumes.

 

You really don't want to abandon dmap shadows, because performance difference is drastic. Engine will have to calculate silhouettes for _everything_, while with dmap shadows it doesn't calculate anything for prelit shadows.

[Tels]

The pic above was a turbo shadow, so not related to dmapped shadows.

 

Like you, I assumed that dmap shadow optimisation would merge the smaller shadow into the bigger one, but for whatever reason it doesn't. Here's the same box reverted to worldspawn with its dmapped (green) shadows:

 

That's very odd, I could have sworn that the example of "merged" shadows was one of the reasons to implement this. But an idea occured to me: Are shadows only merged from different models, but not from the same? E.g. if the big and the small box are different statics, their shadows are merged, but not if they are one and the same (in this case it would result in a sort of self-shadowing optimization).

 

But then, I can't think that this (one or two entities) should make a difference to the code, maybe by accident?

 

Edit: A few interesting links:

• http://fabiensanglard.net/doom3/dmap.php
  
• http://http.developer.nvidia.com/GPUGems/gpugems_ch09.html
  
• https://gamedev.stackexchange.com/questions/84297/stencil-shadows-doom-3-engine-precision-errors-shadow-cracks-why
  

Edited December 9, 2014 by Tels

[Tels]

Yeah, gonna be pretty interesting.

I can try this on an ancient G92b part (GeForce 300 OEM) and a high end 780ti.

 

I can throw in a Geforce 9800 GT (The GT probably stands for "Great Turd"

[Tels]

... maybe moving lights weren't a factor in the original design.

 

Probably not, I don't think the original D3 had many moving lights. A few like the fireball from imps and rockets, but most stuff was fixed IIRC. We did some Very Bad Things™ like making the player light or candles oscillate every frame, which must be a performance killer if moving lights indeed update a lot of stuff.

[Tels]

That seems unlikely to me, since dynamic lighting was very much a showcase feature for the Doom 3 engine when it came out.

 

But there is a difference between "fixed to position" lights, and "moving lights". And it also depends how many lights move each frame. Isuspect we are using not only many more lights, but also many more moving lights. Most lamp fixtures in D3 levels were fixed (e.g. neon tubes, or bulbs) while we have candles and torches, which oscillate. (And interestingly enough, they only oscillate to create live shadows, not because the light point itself needs to move.)

 

Also D3 levels never had more than 2048 entities, so I guess they were much much more limited.

[motorsep]

Moving lights = stationary lights when it comes to performance, assuming they cast no shadows.

 

Stationary lights casting shadows from static meshes (LWO/ASE) and map are _much_ cheaper than shadows cast from moving lights and skeletal geometry.

 

So many moving light + static shadows = ok; many moving lights and dynamic skeletal shadows = death.

[OrbWeaver]

But there is a difference between "fixed to position" lights, and "moving lights". And it also depends how many lights move each frame. Isuspect we are using not only many more lights, but also many more moving lights

 

There were definitely some moving lights; I remember at least one swinging ceiling light in the "mine" levels, and there is a sequence where you follow a guy holding a lantern and have to protect him. But you are probably right in that these were fairly rare examples with only one or two moving lights in the whole scene. The majority of lights were indeed fixed, and those that moved (such as imp fireballs or the plasma gun energy balls) did not cast shadows IIRC.