Shadow volume?

Feedback on past, current, and future development.
User avatar
AnyOldName3
Posts: 2668
Joined: 26 Nov 2015, 03:25

Re: Shadow volume?

Post by AnyOldName3 »

If you've got a light that can change direction, or shadow casters that can move relative to the light, extruding the vertices out requires either the CPU to redo it each frame, which is slow, or that you do it with a geometry shader, which is also slow. You can't precompute which triangles in the mesh are part of the silhouette so can't do better than clever culling (which applies equally to shadow maps, so isn't a gotcha) so you've got to extrude lots of triangles every frame. This is an expensive task (in some cases, the most expensive part) without anything analogous in shadow mapping, and it grows linearly with scene triangle count (but can be pushed in the vague direction of logarithmic with clever culling).

Shadow mapping's task-without-analogue is reading from a depth texture and comparing to the current pixel position. This isn't free, but isn't that expensive, and doesn't get more expensive as shadow-casting triangles are added.

Both algorithms require the casters to all get actually drawn. With shadow maps' depth RTT, you've got triangles the same size they are in the model, and depth writes are on, so it's roughly like rendering the main scene without bothering to colour things in, and you do as many passes as you've got shadow maps. With shadow volumes' stencil-setting-up phase, you're drawing model-size triangles in addition to huge triangles that stretch to infinity (so everything touches lots of pixels) and you've got depth writes off (so can't take advantage of early-z testing to skip loads of stuff and pixels get touched lots of times), so you still have the saving of not colouring things in, but the colossal amount of extra overdraw is extra expense that grows quickly with more potentially-shadow-casting triangles. You have two passes because you've got to do two different things with the stencil buffer, but I imagine in a parallel universe where shadow volumes stayed popular, they'd let you specify a different stencil op for front and back faces - you could emulate this on a modern GPU with atomic writes, but the crazy overdraw would mean you'd spend all your time waiting to acquire locks, so it wouldn't be fast. The gist here is that shadows get cranked up until fill rate limits are hit whichever approach you use, but you hit them with fewer triangles casting shadows with shadow volumes. Anything that lets you skip redundant triangles works for either algorithm as they both care about the same triangles, except early-z (and derivative techniques like tiled renderers) work trivially with shadow mapping and inherently can't with shadow volumes.

As a minor side note, there's also the advantage with shadow mapping that you can do basic alpha testing to use a texture to control silhouettes, but you require geometry with shadow volumes, but modern GPUs aren't big fans of this.

As for the corrupting nature of the profit motive, if Creative really were sitting on a patent that gave them a monopoly on really good realtime shadows, a vaguely-sensible salesperson would set the licence fee at a level that had lots of people paying it - if shadow maps were worse, but the whole industry (except the company I work for, but we don't do depth fail as GL_DEPTH_CLAMP isn't available on GLES and that's a requirement to skip computing per-frame end caps) was using them anyway, then it would mean Creative were letting a guaranteed revenue stream float past them. I'm not saying they were definitely competent enough to set the right price, but if they had, we'd have shadow volumes and years of people complaining about licence fees forcing them to use shadow maps rather than just shadow maps.
Chris
Posts: 1625
Joined: 04 Sep 2011, 08:33

Re: Shadow volume?

Post by Chris »

AnyOldName3 wrote: 05 Feb 2022, 01:43 If you've got a light that can change direction, or shadow casters that can move relative to the light, extruding the vertices out requires either the CPU to redo it each frame, which is slow, or that you do it with a geometry shader, which is also slow.
Or you can do it in the vertex shader, since it will have the vertex/surface normal, vertex position, and light position in world-space. You can calculate there whether you should set the transformed vertex output position to w=1 (vertex is in normal world position) or w=0 (vertex is extruded to infinity). The geometry shader would only be for cases where both the mesh needs explicit edge triangles due to being low fidelity and it's more efficient to use a geometry shader instead of having degenerate triangles in the model.

Maybe I should try to dig out my old code. It's been a really long time since I looked at it and my memory is getting fuzzy with how exactly I had it all working.
AnyOldName3 wrote: 05 Feb 2022, 01:43 Shadow mapping's task-without-analogue is reading from a depth texture and comparing to the current pixel position. This isn't free, but isn't that expensive, and doesn't get more expensive as shadow-casting triangles are added.
There's also a crap ton of PCF filtering to do if you want to clean up the blocks you'll normally get (and while you'd need to do filtering to clean up the sharp edges of shadow volumes too, it's not to the same degree, and unfiltered shadow volumes look better than lightly filtered shadow maps), not to mention issues with shadow acne and peter panning, which at least in Skyrim was still an issue and needed per-light parameters hand-tuned to minimize its effects. You can increase the shadow map resolution to help, ballooning the memory use and fill-rate, though it won't go away completely.
AnyOldName3 wrote: 05 Feb 2022, 01:43 Both algorithms require the casters to all get actually drawn. With shadow maps' depth RTT, you've got triangles the same size they are in the model, and depth writes are on, so it's roughly like rendering the main scene without bothering to colour things in, and you do as many passes as you've got shadow maps.
Though as mentioned, that can be multiple shadow maps per light (up to 6, generating a shadow cube map for point lights that cast shadows in all directions; and something distant like the sun needs PSSM, which splits up the shadow map into multiple). You don't have to write to color with a shadow map (unless you're doing colored translucent surface shadows, where you do need to record the color of the surface along with its depth), but you don't need to write to color or depth with a shadow volume. Shadow maps allow for early-out depth testing... sometimes. If you have a shader that alters the depth value, e.g. if you want to cast shadows onto a parallax surface or if you want to use an alternate depth function to improve depth precision, that may no longer work.

And in either case, triangle count isn't really the problem. We've been at a point for a while now where graphics cards just chew through triangles like nothing (Nanite in UE5 basically makes one triangle per pixel). What is the issue is draw calls and fill rate, and neither of those are friendly with shadow maps. You may be able to get away with one pass for one light source, but you will sometimes need multiple. And increasing the resolution of shadow maps to improve the shadow detail has a direct impact on the fill rate. In contrast, shadow volumes only need one pass per light source regardless of distance or whether it's a spot or point light, and it renders in screen space, so it's fixed at the screen render size (unlike shadow maps where 2048 to 4096, near or larger than a 4K screen, is needed to get decent shadow detail even at 1080p, shadow volumes just need a 1080p stencil buffer for a 1080p screen or a 1440p buffer for a 1440p screen).
AnyOldName3 wrote: 05 Feb 2022, 01:43 You have two passes because you've got to do two different things with the stencil buffer, but I imagine in a parallel universe where shadow volumes stayed popular, they'd let you specify a different stencil op for front and back faces - you could emulate this on a modern GPU with atomic writes, but the crazy overdraw would mean you'd spend all your time waiting to acquire locks, so it wouldn't be fast.
That was already handled: https://people.freedesktop.org/~marcheu ... _side.html Carmack even commented on that in the aforementioned link about the patent:
We were prepared to use a two-pass algorithm that gave equivalent results at a speed hit, but we negotiated the deal with Creative so that we were able to use the zfail method without having to actually pay any cash.
AnyOldName3 wrote: 05 Feb 2022, 01:43 As a minor side note, there's also the advantage with shadow mapping that you can do basic alpha testing to use a texture to control silhouettes, but you require geometry with shadow volumes, but modern GPUs aren't big fans of this.
True, shadows cast from alpha-tested textures can't work with shadow volumes. In that case, doing something more like shadow mapping, perhaps incorporating texture projection or simplified ray-tracing, could help for those kinds of surfaces.
AnyOldName3 wrote: 05 Feb 2022, 01:43 As for the corrupting nature of the profit motive, if Creative really were sitting on a patent that gave them a monopoly on really good realtime shadows, a vaguely-sensible salesperson would set the licence fee at a level that had lots of people paying it
Creative isn't a company that I'd label "vaguely-sensible". This is the company that litigated Aureal and kept them tied up in court until Aureal ran out of money, at which point Creative bought them out and completely squandered their technology which was leagues ahead of anything else at the time. Creative had a habit of buying out competition, which severely thinned out the market for hardware audio cards, which in turn led to the industry abandoning hardware audio altogether. Audio cards were poised to be the first accelerated general-purpose processors, ahead of graphics cards, until the market collapsed.

So, yeah. I'd say Creative isn't a company that seemed very focused on setting and achieving long-term goals, and was more about protecting short-term profit margins, more so than most companies.
Argoon
Posts: 4
Joined: 09 Feb 2017, 16:45

Re: Shadow volume?

Post by Argoon »

Sorry for just jumping in but I need to say some things about this subject.

First the creative patent as expired, so anyone is free to use the "Carmack Reverse" trick without worrying about stupid Creative suing you but know that in modern GPU's it has no visible impact on performance, I know because I work with idtech4 (doom 3 engine).

see https://patents.google.com/patent/US6384822B1/en for expiration status

IMO shadow volumes (or stencil shadows) aren't a total dead end, they can still be a viable option, specially when you have a game, where saving GPU draw calls is important and you still want people with relatively older GPU's be able to play the game. They are faster than most modern shadow maps techniques and btw, both are way faster than the new raytraced shadows.

There are new techniques to make Stencil shadows soft (have a penumbra) that look very good.

Image

Those are Soft Stencil Shadows on Wolfenstein 2009!
Image

They can also be entirely decoupled from the visible geometry complexity, by using a invisible optimized shadow mesh (this can be used for shadow maps as well) many older games using stencil shadows did that.

Is not all good as you guys obviously know, stencil shadows don't support alpha mapping, so no trees or grass casting such shadows, but if necessary in those cases, you can have them on a shadow map pass, at the same time.
And some stencil shadows techniques for more performance, required shadow casting models to be closed (no holes in the geometry) but afaik only a few games used those, Doom 3 for example can have holes in the shadow casting geometry just fine.

Just my two cents for the discussion, now I return to the shadows (pun intended), cheers.
Post Reply