Ultra Shadow and Shadow volume rendering acceleration

[rwolf]

There is an interesting artical about Ultra Shadow

http://www.hothardware.com/hh_files/S&V/ushadow_doom3.shtml

This is a patented technology that gives Nvidia a leg up on future games.

Does anyone know how this compares with ATI's "Shadow volume rendering acceleration" in the 9800?

 

[CorwinB]

I'm not sure, but I've made a point of not trusting any article basing its premises on the Doom3 Benchmarketing figures.

 

[KimB]

I'm really not sure, but I think ATI's improvements to shadow volume rendering in the 9800 center more around fixing problems with using shadow volume rendering in conjunction with Hyper-Z.

In my experience with the Radeon 9700, Neverwinter Nights performance was unreasonably slow with FSAA enabled, compared to how the video card performed in other games. Given the typically low performance hit of FSAA on the 9700, I was surprised. I believe the advancements in the 9800 attempted to fix this problem.

I am unsure whether or not the various FX boards share this same problem, but this technology focuses on something different altogether: it's a way for the game developer to give the video card a hint as to what it may not need to check when rendering a shadow volume. That is, the developer hints to the video card that it doesn't need to render parts of the scene, eliminating some of the workload of the graphics card.

This probably isn't that great of a technology going further down the road, as shadow volume rendering will probably not last very long due to performance reasons (there are other ways to produce shadows....).

 

[Reverend]

The article is not very relevant to me and my personal thoughts about shadow generation.

Shadow volumes (hopefully, anyway!) won't take off in a way that the current hype (either by IHVs or by Doom3, intentionally or not) suggests, other than suggested by the number of Doom3-licensees (such publicly announced licensees or future licensees).

 

[Nick]

I do not fully understand why shadow volumes are this popular. They are physically incorrect and needs several tricks to avoid artifacts (since only light is a physical thing, shadow is 'not light'). Also the thought of having to construct a shadow volume every frame from a complex object seems quite slow to me. Also the overdraw in the stencil buffer is somtimes out of proportion to the shadow created, like with light shining through prison bars or even the foilage of a tree.

I much more like shadow mapping, although I prefer to call it light mapping or light volumes since it describes the volume that can be seen from the light's point of view. Instead of 'adding shadow' it adds light to the pixels that actually are reached by the light's rays. The cost is also only rendering from the light's point of view into a relatively small z-buffer. It also suffers from overdraw but this is just proportional to the scene's complexity.

Anyway, I never implemented any of these techniques, and I understand that shadow mapping has precision issues, but still it looks like a much more elegant algorithm. Probably stencil shadowing just proves more efficient in indoor scenes with only a few low-poly shadow casters? Anyone can shed some shad... euhm, light onto this?

 

[Reverend]

Nick, if you missed it, this thread about shadow rendering techniques may be interesting (damn, that thread is now on page 7 of this forum)

PS. I don't want to hijack this thread of rwolf's about "Ultra Shadow" so if you have any thoughts about what was discussed in that thread, post your thoughts there.

 

[Simon F]

I do not fully understand why shadow volumes are this popular. They are physically incorrect and needs several tricks to avoid artifacts....
I much more like shadow mapping, although I prefer to call it light mapping or light volumes since it describes the volume that can be seen from the light's point of view.

Shadow volumes are no more 'physically incorrect' than shadow maps and, furthermore, it's the latter that are more likely to have artifacts.

 

[Humus]

... which is the only advantage is has over shadow mapping, which has loads of advantages over shadow volumes.

 

[Nick]

Nick, if you missed it, this thread about shadow rendering techniques may be interesting (damn, that thread is now on page 7 of this forum)

PS. I don't want to hijack this thread of rwolf's about "Ultra Shadow" so if you have any thoughts about what was discussed in that thread, post your thoughts there.

Thanks Reverend. The biggest argument I read in that thread is that shadow volumes are supported by any hardware that supports stenciling while good shadow mapping requires things like rendering to 32-bit floating-point off-screen buffers. Seeing that Quake 3 required very low system specifications to have a very big public, I understand that Doom III will take the same route. Although with some more effort different methods could be used depending on hardware support and user's preference.

This brings me back to Ultra Shadow. Why spend die space on a feature that's DOOMed to die? Anything that will help sales is of course justified but maybe they should be looking more towards the future. Although I hope Carmack proves me wrong, I think the game is a bit overhyped. It will definitely be impressive but I expect other games to soon surpass its quality and performance.

I could be very wrong though...

 

[Nick]

Shadow volumes are no more 'physically incorrect' than shadow maps...

I do not think so, but please correct me if I'm wrong...

For example when two shadows from different light sources and objects overlap, this would create a bright spot in the intersection when using shadow volumes. All solutions that I know of are either not elegant or hacks.

With shadow mapping, you effectively model the light instead of the shadow, so that overlapping shadows create no problem. The intersection will just be darker because it does not recieve light from any of the two light sources.

 

[Warrick]

Its interesting that lots of people are starting to be dismissive of shadow volumes now that recently released hardware can deal with shadow maps reasonably well.

Even when the majority of the installed base of hardware has this functionality there are certain effects that are just hard to do without using shadow volume techniques so I'd be careful of being flippantly dismissive of them.

nVidias depth bounds and depth clamping optimisations are interesting and useful techniques and it will be a shame if they are not available on other hardware. Its even more of a shame that they are not exposed under D3D

Warrick.

 

[Humus]

Shadow volumes are no more 'physically incorrect' than shadow maps...

I do not think so, but please correct me if I'm wrong...

For example when two shadows from different light sources and objects overlap, this would create a bright spot in the intersection when using shadow volumes. All solutions that I know of are either not elegant or hacks.

With shadow mapping, you effectively model the light instead of the shadow, so that overlapping shadows create no problem. The intersection will just be darker because it does not recieve light from any of the two light sources.

What you describe is painting shadows instead of painting light. You can do that with both techniques, and you can do it correctly for both. I have on old shadow volume demo that does it correctly, so there's no such artifacts.

 

[mczak]

This brings me back to Ultra Shadow. Why spend die space on a feature that's DOOMed to die?

I don't think that feature uses too many transistors - basically it's the developer of an application which does the hard work, not the hardware.

 

[Nick]

What you describe is painting shadows instead of painting light. You can do that with both techniques, and you can do it correctly for both. I have on old shadow volume demo that does it correctly, so there's no such artifacts.

Thanks Humus, I already thought I was missing something. So how is it solved elegantly?

 

[Simon F]

Shadow volumes are no more 'physically incorrect' than shadow maps...

I do not think so, but please correct me if I'm wrong...

For example when two shadows from different light sources and objects overlap, this would create a bright spot in the intersection when using shadow volumes. All solutions that I know of are either not elegant or hacks.

Definitely not. If you have a DX7+ accelerator try this demo from PowerVR. Source code is available.

 

[Nick]

I don't think that feature uses too many transistors - basically it's the developer of an application which does the hard work, not the hardware.

I see. So how many developers will take advantage of it, if it's not exposed in Direct3D? I'm sure Carmack is 'expected' to use it, but most general custom engines I know just rely on standardized techniques instead of using every bit of hardware specific trick. Most ordinary game programmers already have difficulties getting some basic stencil shadows working, let alone putting their time into implementing something that increases performance by a few percent.

When looking around in game development communities I see the KISS principle is praised very highly nowadays with the ever increasing complexity of graphics programming. So although I agree it's a nice technology, I think most average game programmers are just waiting for a kind of set it and forget it method of working with shadows. Like glEnable(GL_SHADOWS) or d3d->LightEnable(0, TRUE, D3D_SHADOW_ALL). After all, shadow is a basic phenomenon and should be no more difficult than texture mapping, from the programmer's point of view. I think therefore shadow mapping has a better future than shadow volumes.

Anyway, since DOOM III is already predetermined to become one of the standard benchmarks, it is more than logical that graphics card released now have many tricks to speed up its specific needs. I just think it's unfortunate that other games might suffer from this in the sense that their techniques did not get as much attention...

 

[Xmas]

What you describe is painting shadows instead of painting light. You can do that with both techniques, and you can do it correctly for both. I have on old shadow volume demo that does it correctly, so there's no such artifacts.

Thanks Humus, I already thought I was missing something. So how is it solved elegantly?

I don't know how calculating the shadow of one light source could possibly affect the shadow of another light source, since you handle them completely independent with shadow volumes (as well as with shadow mapping).

I agree with mczak that "UltraShadow" doesn't need many transistors. And despite the name, it might be useful not only for shadow rendering.

 

[Nick]

Definitely not. If you have a DX7+ accelerator try this demo from PowerVR. Source code is available.

That's a very interesting demo and technique, thanks! I have to admit that my original argument is wrong.

Still, it is a small hack. The description mentions "the shadow colour for each light is the average colour of the other lights". Although looking fine in this application, it is not completely correct. It should be cumputed per pixel (ok, the demo is DX7) so it attenuates and changes color over distance. In this box the effect can be neglected but for long hallways or terrains it is essential. I think it would be quite hard to correct this with this technique, but if it's possible please prove me wrong again.

I believe that shadow color is inherently correct with shadow mapping, again because it models the light and not the shadow...

 

[Simon F]

Definitely not. If you have a DX7+ accelerator try this demo from PowerVR. Source code is available.

That's a very interesting demo and technique, thanks! I have to admit that my original argument is wrong.

Still, it is a small hack. The description mentions "the shadow colour for each light is the average colour of the other lights".

That's not a requirement of the technique - you just change it to add lighting when you're out of each shadow.

I believe that shadow color is inherently correct with shadow mapping, again because it models the light and not the shadow...

No, shadow maps (as invented by Lance Williams (same guy who invented MIP mapping), are effectively the same. It simply decides if a pixel location is inside or outside of a shadow. It's up to you to shade it correctly! (Actually, Williams deliberately put in a short cut in his shading that caused specular highlights to be wrong)

 

[Nick]

That's not a requirement of the technique - you just change it to add lighting when you're out of each shadow.
...
No, shadow maps (as invented by Lance Williams (same guy who invented MIP mapping), are effectively the same. It simply decides if a pixel location is inside or outside of a shadow. It's up to you to shade it correctly! (Actually, Williams deliberately put in an short cut in his shading that caused specular highlights to be wrong)

Ah yes, I see it has more potential than I thought. Thanks again for opening my eyes.

Still one more argument I'm going to annoy you with. If I got it correctly, this requires multiple passes over the whole framebuffer. This requires quite a lot of memory bandwith I suppose. For shadow mapping, lighting can be completely computed per pixel in one pass.

Now that I think of it... how can you do per-pixel lighting with stencil shadowing if you don't have the surface properties? If I'm correct then all you have is the base texture color? It would require an extra buffer to store the intermediate results of the sum of light modulations. Also things like per-pixel bumpmapping information is not available, except of course if you write that to an extra buffer the size of the frame buffer. This in turn requires extra memory and bandwidth. Also, to compute attenuation you need the distance to the light source. While it is possible to use the z-buffer's value for this, it again requires extra bandwidth. With shadow mapping all these parameters are available interpolants anyway.

I'm still a bit confused, but thank you all for clearing up some of this stuff!