[Reverend]

After some discussion with Ubisoft re Splinter Cell, we (i.e. me and my Ubi contact/programmer) agree on the following :

Most people agree that there are 4 major shadow rendering techniques in computer graphics at the moment :

(1) stencil shadow volume, as will be used by Doom 3
(2) shadow buffers, as used by Splinter Cell in its GF3/4Ti/FX "version"
(3) shadow projectors (projected textures), as used by the Radeon cards in Splinter Cell
(4) ray tracing-based, which is not used in real-time computer graphics (far, far too slow).

Ubi says that the Splinter Cell projected texture algorithm is certainly one, if not the most, complex implementation of this algorithm in a game ever.

Given the current generation of hardware, and the way "forward" as suggested by these hardware and the hype generated by (1) above, I was wondering what folks here has to say about the pros and cons of each and every technique listed above.

Note that this discusson can be related to lighting algorithms, which Kristof suggested to me in a separate internal matter, like quad-lighting.

PS. Don't ask me what shadow technique (as well as other 3D tech) Splinter Cell 2 would be using... coz, well, I can't tell

[pcchen]

Just some major points:


Stencil shadow volumes

Pros: robust (with Carmack's reverse and infinite planes), simple to implement, widely supported by display hardwares (requires only stencil buffer)

Cons: eats lot of fillrate (except for tilers), hardware accelerated shadow volume generation is complex or slow, hard edges, handles geometry only (no alpha textures)


Shadow buffers

Pros: simple to implement, hardware accelerated (few or no CPU intervention), can mimic soft shadows

Cons: not so robust, requires special hardware support, need different kind of textures for different kind of lights (directional vs point)


(non-prioritized) projected shadows

Pros: hardware accelerated (few or no CPU intervention), can mimic soft shadows

Cons: not robust, need different kind of textures for different kind of lights (directional vs point)

[Ostsol]

Does "shadow buffers" refer to projected shadowmaps that that use the z-buffer?

[Chalnoth]

I just have to say...unless shadow buffers can be used easily to shadow the entire scene, they pale in comparison to stencil shadows. I still think that once DOOM3 comes out, it will quickly become very important to apply shadows to everything (a few games already do it, such as NWN, and it looks fabulous, but DOOM3 will have the circulation required to really get people to see how good global shadowing can look).

Oh, and Ostol, here's nVidia's white paper on how shadow maps are done on the GeForce3 (and beyond, presumably):
http://developer.nvidia.com/view.asp...hadowmap_paper

It appears that the technique uses a texture as sort of a second z-buffer for the shadow mapping.

[Ostsol]

Ah. . . that's what I thought. . . Strange that Splinter Cell only uses this for NVidia cards since the Radeon 9500 and up support it, too. . . *shrugs*

[Rodéric]

AFAIK you can use shadow maps to shadow everything just like you use the inefficient shadow volumes.

Anyway as long as it works almost ok.

I don't see the point of having say... PIKMIN with a global shadowing scheme.

[ERP]

Originally Posted by Chalnoth

I just have to say...unless shadow buffers can be used easily to shadow the entire scene, they pale in comparison to stencil shadows. I still think that once DOOM3 comes out, it will quickly become very important to apply shadows to everything (a few games already do it, such as NWN, and it looks fabulous, but DOOM3 will have the circulation required to really get people to see how good global shadowing can look).

Oh, and Ostol, here's nVidia's white paper on how shadow maps are done on the GeForce3 (and beyond, presumably):
http://developer.nvidia.com/view.asp...hadowmap_paper

It appears that the technique uses a texture as sort of a second z-buffer for the shadow mapping.

There was a Siggraph paper last year "Perspective shadowmapping" that addressed the whole scene issue. Shadow maps have a lot to recommend them from a hardware implemention and performance standpoint.

Stencils IMO offer a better overall solution but at a significant cost, they provide a pixel accurate determination of lit/non-lit in screen space rather than lightspace which prevents some of the potentially horrid aliasing that can occur.

Moving forwards I think you'll continue to see variations on both approaches, there are ways to extend both to provide approximate soft shadows, which makes more sense is going to be dependant on the application for a while to come yet.

[nAo]

Originally Posted by ERP

There was a Siggraph paper last year "Perspective shadowmapping" that addressed the whole scene issue. Shadow maps have a lot to recommend them from a hardware implemention and performance standpoint.

Unfortunately PSM introduces new problems with lights behind the camera..

[Colourless]

Originally Posted by Ostsol

Ah. . . that's what I thought. . . Strange that Splinter Cell only uses this for NVidia cards since the Radeon 9500 and up support it, too. . . *shrugs*

Under DirectX 8 ATI cards do not support texture formats with high enough Bit Depths to do Shadow Buffering. In DirectX 9 though they could use the D3DFMT_R32F format on ATI cards, in theory, of course that format doesn't support filtering. Otherwise they might be able to use D3DFMT_G16R16 if it has high enough precision.

This assumes they are doing shadow buffering how I think they would be doing it.

[ERP]

Originally Posted by nAo

Unfortunately PSM introduces new problems with lights behind the camera..

Agreed, but given the benefits of being able to use a single shadow map for your entire scene, the cost of solving them is acceptable IMO.

[Ilfirin]

First, both shadow volumes and shadow buffers/shadow mapping cause shadowing on/from all objects, so they are a rather apples to apples (in this regard, atleast) comparison.

Shadow volumes are slow, nasty, and rather ugly. They don't scale well at all with polycounts, eat up precious CPU cycles (it's still usually much better to do the calculations on the CPU than in the vertex shader) and have tons of little subtleties (shadow popping, don't work *correctly* on transparent and translucent textures, etc). And the solution [to shadowing] is far from elegant (IMO of course).

Shadow buffers/Shadow mapping (I'm assuming the general card-independent algorithm, regardless of hardware support), on the other hand are a very conceptually elegant solution (.. IMO again), they do scale well with polycounts, and they do work with transparent textures. The problem, of course, being that they have aliasing problems and that you might end up using 2 or 3 different texture types (paraboloid, dual-paraboloid, planar) and thus 2 or 3 different shaders for the different types of lights (point, hemi-spherical, spot, and directional). The latter only really affects the programmer's work-load, so that's neither here nor there. For the former, there exists several methods of cutting down on aliasing problems (perspective shadow maps, PCF, super-sampling, and of course just upping the texture resolution), some of which have their own side-effects as well.

The last 2 methods are either not real-time, or static/hacked and thus who cares?

Out of those, I would personally choose (2) now. I used shadow volumes for about a year (when they were the only real option, as hardware shadow mapping was just becoming available and it really sucked then), and can honestly say I absolutely hate them

The choice "more" people are going with for 'going forward' wasn't listed at all though, and that's spherical harmonic based radiance transfer (which, according to the Sweeney interview on FiringSquad, is what the new Unreal engine is doing). I personally am not too fond of SH shadowing (which seems to be everyone else's obsession with them). I would rather just use shadow buffers with a DoF blur to get some rather nice aestheticly correct soft-shadows (the quality is completely dependent on how you do your blurring, of course) and use the SH's for surface-local, arbitrary BRDFs maybe with a surface-scattering term. Then you can get really really really nice, physics-based lighting, with rather nice, robust soft-shadows and none of the 'no deforming models', or multiple shadows convultion problems and such. And also, if you're using shadows as a gameplay mechanic, you really don't want SH's overly softness because then there's no where to hide (unless you limit yourself/stealth to purely dark areas).

[Hellbinder]

Slightly OT.

I just bought a PS2 yesterday and rented a few games. The Best of which is Tribes 2 Areal Assult. (i also got the lan adapter ).

This topic fits right in to what i was pondering yesterday. What kinds of Shadow support is the EE/GS of the PS2 capable of? Probobly projected shadows for sure.. But what about. Stencil shadows or the other methods? Is a Doom-III style dynamic shadowing possible?

btw, what method does Splinter cell for PS2 use?

[Reverend]

Originally Posted by Colourless

Under DirectX 8 ATI cards do not support texture formats with high enough Bit Depths to do Shadow Buffering. In DirectX 9 though they could use the D3DFMT_R32F format on ATI cards, in theory, of course that format doesn't support filtering. Otherwise they might be able to use D3DFMT_G16R16 if it has high enough precision.

This assumes they are doing shadow buffering how I think they would be doing it.

From Splinter Cell's v1.2 patch readme :

On NV2x/NV3x hardware, it runs using a technique called Shadow Buffers. This technique is rendering the scene from every shadow casting light and store a depth buffer that represent each pixel viewed by this light source. Each pixel has an X, Y, Z coordinate in the light system and these coordinates can be transformed, per pixel, in the viewer coordinate system. It’s then easy to compare with the actual depth stored in the Z buffer to figure out if the pixel viewed by the camera is the same or is occluded by the pixel viewed by the light. If they are the same, it means the pixel is lighted, if the light pixel is in front of the viewer pixel, it means the pixel is in the shadow. On all other current hardware, the game is using another technique called projected shadows (shadow projectors). The technique is somewhat similar, we render the scene from the light point of view but instead of storing the depth, we are storing the color intensity in a texture. That texture is then mapped per vertex on each object that is going to receive the shadow. To be able to have objects casting shadows on other objects that are themselves casting shadows, Splinter Cell is using a 3-depth levels shadow casting algorithm. In general, the first level is used to compute the shadow to be used on the dynamic actors like Sam. The second level is used to compute the shadow used by the static meshes like a table or boxes. The final level is used for the projection on the BSP. This system is allowing Sam to receive the shadow of a gate on him, then Sam and the gate can cast on a box and finally all three objects can cast on the BSP (ground). This system also has a distance check algorithm to determine if Sam’s shadow should be projected on a static mesh (like a box) or if it shouldn’t base on their relative position. Both systems have their own strength/weaknesses.

Basically, Splinter Cell is using a lot of single texturing (with color) for the shadow effects. In shadow buffer mode, rendering is from the light point of view with Z/Stencil only (well not exactly true, alpha and even color sometime for full and partial color transparency).

[Ilfirin]

Right, but the technique itself isn't exclusive to nVidia cards (just elaborating on someone else's earlier post).

In DX8* & 9 you can simply render the scene from the light's point of view and write the depth to a texture (i.e. calculate depth in the vertex shader and interpolate it to the pixel shader, that then writes it to a texture). All the extra 'crud' will be rejected by the depth and alpha tests, leaving you with the functional equivalent of the depth buffer from the light's POV (ala nVidia's implementation). You would then use this texture just as you do the texture that results from nVidia's 'depth buffer render target' implementation. In principle you are doing pretty much the exact same thing (at least I believe so, but I admit I'm not too familiar with the internals of nVidia's implementation), just nVidia's method is faster, theoretically nicer and comes with automatic PCF.

*While doing a vanilla render-to-texture in DX8 would have really bad precision artifacts, you can pack the depth info into multiple channels to achieve higher precision.

ATi has demos of all this (both with the multi-channel packing (DX8.1) and with DX9 high-precision formats) at their public developer site.



And Hellbinder, the PS2 excels at rendering untextured polygons, ala shadow volumes. So yes, it can. Lighting is another issue, of course.

[nAo]

Originally Posted by Ilfirin

just nVidia's method is faster, theoretically nicer and comes with automatic PCF.

that's the main point to me, without PCF it is quite fugly, imho.

And Hellbinder, the PS2 excels at rendering untextured polygons, ala shadow volumes. So yes, it can. Lighting is another issue, of course.

Unfurtunately PS2 has no stencil buffer support, but that can be emulated with a standard color buffer. The real problem is that ps2 cannot do lessthanequal ztest , so in order to perform stencil shadows ala carmak's reverse you have to reverse the zbuffer. Zbuffer reversing cause slighty errors and that introduces artifacts.

ciao,
Marco

[Ilfirin]

Originally Posted by nAo

that's the main point to me, without PCF it is quite fugly, imho.

Yes, but you can also do manual PCF in the pixel shader (as Ati's demo also does). Granted it's a lot slower..

[fresh]

The PS2 can do projected shadows, stencil shadows and at the recent devcon they showed how you can even do shadow maps. We use stencil shadows w/ inverted zbuffer and they work great for us.

SH's are nice. Haven't looked into how to deal with deformable objects though (skinned characters for example).

[Humus]

Originally Posted by Reverend

(1) stencil shadow volume, as will be used by Doom 3
(2) shadow buffers, as used by Splinter Cell in its GF3/4Ti/FX "version"
(3) shadow projectors (projected textures), as used by the Radeon cards in Splinter Cell
(4) ray tracing-based, which is not used in real-time computer graphics (far, far too slow).

(1) Stencil shadow volumes has one advantage, being pixel perfect, but has loads of disadvantages. Will most likely not be used in Carmack next engine after DoomIII.
(2) Simple, elegant, scalable and efficient. It has only one disadvantage, the aliasing problem, which there are solutions to.
(3) Shadow projectors can be quite useful for the restricted cases to which it applies, and gives soft shadows more or less automatically. Being static except for simple rotations etc. though it's fairly restricted.
(4) Will most likely never be particularly useful for realtime.

[Humus]

Originally Posted by Colourless

Under DirectX 8 ATI cards do not support texture formats with high enough Bit Depths to do Shadow Buffering. In DirectX 9 though they could use the D3DFMT_R32F format on ATI cards, in theory, of course that format doesn't support filtering. Otherwise they might be able to use D3DFMT_G16R16 if it has high enough precision.

This assumes they are doing shadow buffering how I think they would be doing it.

For range limited lights (that is, most lights in games), 8 bits can get you fairly far. More than 16 bits are useless for shadow mapping.

[Nick[FM]]

Hmm.. Are there any tech demos which use Perspective Shadow Mapping? I have got the impression that it is very good looking, and the performance is good too.. I'm not so into this stuff, so maybe I just stay quiet!

But a tech-demo or something would be nice..

[Saem]

OT:

I just bought a PS2 yesterday and rented a few games. The Best of which is Tribes 2 Areal Assult. (i also got the lan adapter ).

How replayable is it? How's the bot AI, graphics, sound? How many human players can play together? What's the control scheme like, is there support for a USB kb?

[Reverend]

Tim Sweeney regarding this topic.

If JC will forget the fact that I bug him a lot, I'm hoping for his comments.

[Hellbinder]

How replayable is it? How's the bot AI, graphics, sound? How many human players can play together? What's the control scheme like, is there support for a USB kb?

MODS: I promise not to go any furthe OT than this one reply.

-Replayability = 10
-Graphics = 7
The game plays just like Tribes 2, wtih much beffed up player models and vehicle detail is a lot better to. Is not missing any feature of the big game other than Voice. All game modes are present as well. The maps are a bit simpler of course but still nice. It includes all the best maps from the origional and adds a few more.

-Bot Ai = 8
I was immidiately impressed. The bots on your team automatically assume offense, defense and support roles. Within min of starting a match they will have a remote equipment station set up, sensors etc.. they fight pretty damn good to. Its pretty fun to max the bots out to 8 and play a little 4x4 match.

-Multiplayer = Wooohoo
The game supports 2 player split screen with a max of 3 bots on each team. But the best part is it supports 16 player internet matches. You can even host your own internet game. There are a few cool configuration settings you can do to. like Auto target lock on and off etc. Once in the game its Tribes 2 all the way. Except everyone is perfectly evenly matched with the exact same performance. Heck they even included the voting support. You can vore to change maps, kick players etc. My absolutly Favorite thing about it is this.. it will let you have 2 players split screen on your PS2 and connect to an online game like that. The two of you sitting there like a little team busting it up online. It is truely a cool feature. I was also impressed to find 32 servers online most with 16 players maxed out, that was a shocker. there are a coupple hundered people playing Tribes on PS2 24/7

-Control = 7/10
the controls mapped to the controler are great. It only took me a few min to start raging on people. I cant really go through all the buttons, but trust me they nailed it as far as a controler goes for a FPS. Yes it does support keyboard and mouse.. but i have not been able to test it yet. I am going to buy the Fancy Everquest PS2 keyboard on Friday, so ill have a better idea.

They even threw in an little single player Campaign. Imagine that.

[NeARAZ]

Tim Sweeney on stencil shadow volumes:

Requires lighting geometry to be identical to scene geometry

With some techniques you can have the simplified geometry for the volumes, have self-shadowing and have the volume being generated entirely on the GPU - eg. "reverse extruded shadow volumes" - http://www.gim.ktu.lt/nesnausk/nearaz/texts/revext.html. This isn't cure in all the cases, but in some of them it works.

That aside, stencil still eats lots of fillrate...

[Hyp-X]

Originally Posted by worm[Futuremark

]Hmm.. Are there any tech demos which use Perspective Shadow Mapping? I have got the impression that it is very good looking, and the performance is good too.. I'm not so into this stuff, so maybe I just stay quiet!

But a tech-demo or something would be nice..

We use perspective shadow map for a single light source (sun).
It's a top-down view outdoor game (it's RTS after all) so it suits it perfectly.
It works on all DX8 hardware.
There are 4 implementations to cover all those cards: PS1.2 (8bit), PS1.4 (12bit), PS2.0 (16bit), nV depth-textures(16/24bit).

I was quite impressed with the quality of even the 8bit version.
Surprisingly the nV version has quiet a few problems due to not being flexible enough to adopt the perspective shadow maps correctly.
This causes the precision of the shadow buffer to drop with the distance from the viewer.
(I have some ideas for that but don't yet know if it will work well with large surfaces.)

No public demo yet unfortunately.
Maybe if you attend E3...