Doom III Referesher

Yet, I can't help but marvel at the realism of seeing a guard wandering around with a torch in hand who is projecting shadows against walls that realistically shrink or grow (depending on distance) in a way that only shadow volumes seem to be able to achieve. I just wish this magic was happening 100% on my GPU...
I guess you haven't done much experimenting with a torch then. :) Sure if you're hiding in a cave on mars with only your flashlight it might be sort of real. But light tends to bounce of objects. And as said environment makes a huge difference. Also don't confuse "looks real" with "looks cool".
 
@ MDolenc
Yeah, real torches don't tend to produce the kind of sharp shadows and specific light direction of a flashlight but having the shadows react three-dimensionally to the light source is worlds better than shadows that are painted to the ground as in, say, Max Payne 2 (great looking game anyway). If you have a specific dynamic shadow method that you feel trumps Doom 3's (Cryengine maybe?) then I respect that. I just have this superstitious belief that John Carmack was laying the groundwork to transition to Ray-Tracing so I hold the engine in some (probably) unqualified esteem.

@Davros

I have no qualifications to judge the greatness of another mind, so I'll take your word for it ;)
 
The shadow volume CPU processing was not the main reason stencil shadows got replaced by shadow maps in all recent engines. Stencil shadow volume GPU extraction was possible and pretty fast even on DX8 GPUs. In our old DX9 engine we used fully GPU generated stencil shadows extensively and all our benchmarks indicated that GPU extraction was noticeably faster than CPU extraction. (we had around 20-30 fully uniformly shadowed light sources in view at once).

Yes, stencil shadow extraction on DX9 GPUs doubled the vertex count of the volume, but since the volumes were rather low poly, this basically didn't affect the performance at all (the bottleneck was never the vertex shader performance). The biggest drawback of stencil shadows has always been the massive stencil fillrate it requires when multiple shadow volumes are crossing the view in a bad angle. The performance is really view dependant and a slight change in viewing angle can drop the performance dramatically. It's really difficult for artists to tweak the performance of stencil shadowed scenes, as the algorithm performance is so erratic.

Positive things about stencil shadows:
- Stencil shadows combine really well with deferred shading, especially with LiDR (light indexed deferred shading).
- With stencil shadows you have to light only the pixels that receive light. Stencil test skips the complex deferred lighting shader completely for pixels that are in shadow. This saves around 30% of the (deferred) lighting shader performance.
- Stencil shadows use much less memory than shadowmaps.
- Stencil shadows use much less texture memory bandwidth than shadowmaps. The rendertarget bandwidth usage is however much larger (but in systems like Xbox 360, the render target is located in really fast EDRAM to provide practically unlimited bandwidth).
- Stencil shadows are pixel perfect and have no surface acne, no blockiness, no sample walking issues in moving lights, etc... For example self shadowing looks really good and requires no tweaking (good looking self shadowing has always been hard to do with shadow maps).

Negative things:
- Performance is sometimes good and sometimes abysmal. A simple chain link fence can drop the game to 1 fps if the camera looks along it.
- No alpha masked shadow casters are possible. Plants, trees and vegetation are all almost impossible to render properly with decent performance.
- For fast (DX9) GPU volume extraction the shadow meshes have to be closed surfaces. In DX10/11 you can likely use geometry shader to render more freely formed geometry efficiently.
- Deferred shading light area combination tricks do not work with stencil shadows, since stencil test can only fail or succeed (not succeed for one light and fail for the other). So you have to render each light separately (and this causes extra g-buffer reads and backbuffer blending).
 
r_useLightCulling:
0 = none,
1 = box,
2 = exact clip of polyhedron faces,
3 = also areas

( not sure about the : )
 
Thanks for the info Davros...

I will test these to see if they affect the number of interactions...

I really wish there was an "r_interactionsTableMegs" cvar but beggars cant be choosers...
 
I figured I would keep my rambles in one place...

The Dark Mod team have found out how to get the Linux version of the Doom 3 SDK to recognize CPU types (CPUID) in the hopes of adding in SIMD support. Shortly after this, they began to look at upgrading to a more recent version of the "Boost" library.

So following this progression:

1) There is a Boost.SIMD library, I presume that this would count as a "SIMD Provider"?
2) There is also Boost "Thread" which spawns SMP threads for certain function?

So if the CPUID can also identify the number of cores then the new Boost libraries could utilize those cores for certain SDK processing?

I also hear that Boost has experimental OpenCL backends?

Finally, if any of the above is possible or feasible, would farming (for example) path-finding out to a Boost Threads library be a sneaky way to make the engine utilize SMP?

Would it be beneficial or is there some caveat I don't know about?
 
Back
Top