NVIDIA's UltraShadow in Doom3
- Thread starter Reverend
- Start date
- Status
IT's not like doom3 uses shadow volumes nearly as intensively as expected.
No global illumination in the end, lightmaps galor and monsters and some objects casting shadow volumes...
Given those, it wouldn't be much of a surprise if the depth bound test doesn't provide great/good speed improvement.
my 0.02€
No global illumination in the end, lightmaps galor and monsters and some objects casting shadow volumes...
Given those, it wouldn't be much of a surprise if the depth bound test doesn't provide great/good speed improvement.
my 0.02€
HUGE!Reverend said:
I go from 12-40fps to 30-60fps. It's the lack of them low-dips in combat situation and shadow intensive rooms that is really noticeable, but there are still plenty of light-mapped shadows to provide the ambience.
digitalwanderer said:HUGE!Reverend said:
I go from 12-40fps to 30-60fps. It's the lack of them low-dips in combat situation and shadow intensive rooms that is really noticeable, but there are still plenty of light-mapped shadows to provide the ambience.
This may be due to the heavy CPU-load of Doom3's implementation of shadowvolumes, not due to the fillrate requirements itself, and since UltraShadow only reduces fillrate, Doom3 would only benefit if it was fillrate-limited, not CPU-limited.
From my own experience, and from Carmack's interview, I assume that it is indeed CPU-limited.
Just about any softshadow you see is projected light/shadow textures, the stencil shadows are hard and absolutely black.SteveHill said:
A significant bottleneck I've encountered (6800, AthlonXP 2400+) isn't stencil shadows, but rather the sheer number of draw calls in some areas, which is mainly a product of the number of discrete surfaces and the number of participating lights. I've only looked closely at the multiplayer maps so far, so I can't say how indicative this study is, but it's a good way of analysing problem locations, without AI and so on getting in the way. I'll get on to why I think it could be representative though, in a mo'.Reverend said:
As an example, there's one problem spot in d3dm1 where the framerate drops to around 20-25. This framerate is independent of fillrate -- at least up to medium resolutions (1024x768) -- and, specifically, vertex and fragment processing are not bottlenecks as I've tested with a null interaction shader and the frame rate is largely unaffected. The framerate is also barely increases when shadows are disabled.
So, what's gobbling up the FPS? Well if one disables lighting (r_skipInteractions), the framerate shoots up to the 60hz cap. Now, even without shadows enabled, we might be CPU limited from lots of light-surface testing in software and if one looks around with the nulled lighting shader and just the torch light source active (interactions enabled again) one can see individual faces being 'touched'. If, however, we instead disable the rendering context (r_disableRenderContext) so that driver calls are nulled, the same CPU processing still occurs but the framerate is again up at the 60 cap.
This all strongly suggests that the bottleneck is driver-related and one only has to dump a GL log to see a frightening number of glDrawElements calls per frame (around 1150 in this case) with lighting enabled, dropping to a far more reasonable figure when disabled (350 or so). This is an unfortunate reality of the main lighting and shadowing system coupled with lots of texture variation. It's tricky to batch effectively in the case of the latter anyway but the problem is multiplied by the number of lights, which you can't process in groups due to the serial restriction of shadow volumes.
In fact, if you try setting all surfaces in the scene to use the same material, you still get roughly the same number of calls (some special materials are multipassed even with arb2) -- the engine doesn't even attempt to optimise this unlikely scenario! Of course in-game there are other potential bottlenecks, but we're talking about rendering here and I believe this is a general issue, but with perhaps less attention paid to it by the creators of the multiplayer maps.
Really? I didn't notice that, I'll make sure to check it out later.
Thanks Chal, if the shadows actually have some tones to 'em I think I'd like 'em better.
Thanks Chal, if the shadows actually have some tones to 'em I think I'd like 'em better.
The problem is that Doom3's bumpmapping doesn't work without a lightsource. The light is calced per pixel from the surface normals read from a bumpmap and the lightvector to the current lightsource.
Without a lightsource, there is no lightvector, so there is no light that can be calced with the bumpmap, so with a regular ambient light factor, or with lightmaps, the surfaces would just look flat.
Perhaps they decided that full black looks better than flat textured surfaces.
Lightmaps could have some kind of precalced bumpmapped light, but perhaps they chose against using lightmaps because they'd take up too much memory, especially if you want to have bumpmap details.
HalfLife 2 has a solution to the problem, they have developed a normalmapped radiosity algorithm, which works quite nicely.
You can find a description of the algorithm here: http://www2.ati.com/developer/gdc/D3DTutorial10_Half-Life2_Shading.pdf
I expect HalfLife 2 to look better than Doom3 and also run faster, it seems to have a much more up-to-date shading system.
Luminescent
Veteran
Anyone have a link to an article describing Doom 3s rendering methods in detail?
It would be a great idea if someone made an extensive article comparing the rendering advantages/disadvantages of all three major engines, including Doom 3, Crytek, and Source. How do their lighting, shading, texturing, etc. systems compare? What is each suited best for and which way are we headed? Maybe such an article exists already, who knows?
Anyways, with individuals like Rev that have a few connections, I think such an article would be quite plausible.
It would be a great idea if someone made an extensive article comparing the rendering advantages/disadvantages of all three major engines, including Doom 3, Crytek, and Source. How do their lighting, shading, texturing, etc. systems compare? What is each suited best for and which way are we headed? Maybe such an article exists already, who knows?
Anyways, with individuals like Rev that have a few connections, I think such an article would be quite plausible.
Doom3's shadowing is pretty much explained here: http://developer.nvidia.com/object/robust_shadow_volumes.html
The lighting is quite standard per-pixel phong-style rendering, using normalmaps. You can find the exact shader code for Doom3 in the 'pak000.pk4' file (open with WinRar) in the glprogs subdirectory. Interaction.vfp is the main pixelshader.
It is most probably also covered in some NVIDIA presentations, but it is very straightforward anyway.
Pretty much the usual:
(saturate(normal.light)*texture + saturate(normal.specular)^shininess)*attenuation
Where the power-function is approximated by some hack... For example, for an exponent of 16, this function is a reasonable approximation:
(x^2-0.75)*4
It can be implemented by a single mad-instruction.
In some codepaths the function is evaluated via a texture instead (NV3x-specific optimization, as Humus demonstrated, bad bad bad on ATi).
Light vectors are normalized per-pixel with a cubemap (another NV3x-specific optimization, arithmetic would have yielded better quality, and balance between texture and arithmetic operations better).
Normals from the normalmap texture are not renormalized.
I don't know anything about FarCry myself... and all I know about Source is what is in the PDF I linked to before. The PDF mentions that they have close to 2000 shaders though, so it seems like they have a very varied shading system. Doom3 basically has one main surface shader, and some special effects.
The lighting is quite standard per-pixel phong-style rendering, using normalmaps. You can find the exact shader code for Doom3 in the 'pak000.pk4' file (open with WinRar) in the glprogs subdirectory. Interaction.vfp is the main pixelshader.
It is most probably also covered in some NVIDIA presentations, but it is very straightforward anyway.
Pretty much the usual:
(saturate(normal.light)*texture + saturate(normal.specular)^shininess)*attenuation
Where the power-function is approximated by some hack... For example, for an exponent of 16, this function is a reasonable approximation:
(x^2-0.75)*4
It can be implemented by a single mad-instruction.
In some codepaths the function is evaluated via a texture instead (NV3x-specific optimization, as Humus demonstrated, bad bad bad on ATi).
Light vectors are normalized per-pixel with a cubemap (another NV3x-specific optimization, arithmetic would have yielded better quality, and balance between texture and arithmetic operations better).
Normals from the normalmap texture are not renormalized.
I don't know anything about FarCry myself... and all I know about Source is what is in the PDF I linked to before. The PDF mentions that they have close to 2000 shaders though, so it seems like they have a very varied shading system. Doom3 basically has one main surface shader, and some special effects.
Luminescent
Veteran
I believe that source rilies more heavily on its material shaders and less on procedural dynamic lighting; more static lightmaps.
- Status
Similar threads
- Deleted member 2197
- Games Industry
