Sign in to follow this  

Basic shadows efficiency question

This topic is 4727 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I'm working on implementing stencil shadows for my game... Anyways, it seems to me that stencil shadows only depend on the complexity of the shadow-casting object... So, if the receiver has a crapload of polys, or if the receiver is just a simple plane, you'll get the same results either way, right? I was wondering, does shadow mapping have this same benefit? I haven't heard it mentioned anywhere, but logically I'd imagine that shadow mapping would depend on the complexity of the receiver... Thanks, roos

Share this post


Link to post
Share on other sites
Hi,

I wouldn't say that the complexity of the receiver have no impact at all.. You still need to render receivers at least twice (assuming 1 light, you need a Z pass, then the lighting pass using the stencil mask). But then, this is usually not as bad for performance and fillrate as the edge/silhouette detection, shadow volume extrusion and rendering of the casters.

For shadow mapping, I'm not 100% sure, but I think the bottlenecks will be the render target changes, and the number of times you sample the shadow map if you want soft shadows.

Share this post


Link to post
Share on other sites
of course using more polygon models is gonna run slower in both methods,
shadowmaps scale better then stencil shadows for higher polygon models WRT creating the shadows in the first place. ie stencil shadows require a lot more work per vertex

Share this post


Link to post
Share on other sites
Thanks for the replies guys!

Hmm, I need to render the receivers twice? I think I see what you're talking about, using your method it would be more accurate because then instead of lighting areas without any shadow and then darkening them, you simply don't light areas which are in shadow.

I'm not too worried about perfect accuracy though, so I think I can get away with only rendering the receiver once, right? Here's what I'm doing, below.

// visible pass
1. Render the entire scene normally (receivers, occluders, everything)

// shadow pass
1. Enable stencil buffer, disable Z write and color buffer
2. Render front faces of extruded shadow volumes (+ increment stencil buffer)
3. Render back faces of extruded shadow volumes (+ decrement stencil buffer)
4. Render black quad covering the entire scene (pass stencil test for >= 1)

Thanks a lot!

roos

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by roos
4. Render black quad covering the entire scene (pass stencil test for >= 1)

Theres your snag right there. Thats a horrible, hacky, unrealistic method of doing shadows. I have no idea why its a popular method of doing things (although I suspect one of the D3D example apps may be to blame).

Ideally you do one pass per each light (and a single ambient/z pass as before)-
1. clear stencil
2. mask off shadow areas as before in stencil buffer (with front & back inc/dec)
3. Re-render your scene geometry illuminated by the current light (but rendered *only* where you don't have shadows). This re-rendering should be added to the current framebuffer.

That gets you proper behaviour when multiple lights and their shadows overlap.

OT.

Share this post


Link to post
Share on other sites
Thanks very much Anonymous Poster for your great explanation :) I understand now.

For now I'll implement it the "hack" way, then later if it turns out there's still frames to burn after all the pixel shaders and effects have chewed up time, then I'll upgrade to the more correct version :)

Btw, I read about this technique from "Real time rendering tricks and techniques in DirectX" (book in the Prima press series). It's actually a good book at least at an introductory level, and the author did mention the technique was incorrect since you're lighting and then darkening.

roos

Share this post


Link to post
Share on other sites
Quote:
Original post by roos
Hi,

I'm working on implementing stencil shadows for my game... Anyways, it seems to me that stencil shadows only depend on the complexity of the shadow-casting object... So, if the receiver has a crapload of polys, or if the receiver is just a simple plane, you'll get the same results either way, right?

I was wondering, does shadow mapping have this same benefit? I haven't heard it mentioned anywhere, but logically I'd imagine that shadow mapping would depend on the complexity of the receiver...

Thanks,
roos


Depends what you mean by complexity. Stencil shadow systems are very difficult to make performent due to pathelogical load problems due to fillrate. Imagine a fence grating trying to cast a shadow - it can overdraw every pixel on the screen dozens of times. It also increases complexity for more advanced lighting and filtering due to its preference to deferred rendering.

Most of the software complexity involved in a stencil shadow system relies on determing wether an occluder is already enclosed in a shadow volume, so that it doesn't have to be drawn. This can get fairly complicated, and it still doesn't cap the max complexity of any given seen. Many people have had to pull stencil shadow systems late in the game cycle becuae they just don't perform well enough.

Shadow maps, on the other hand, are always a bounded by a linear time. In fact, most Offline rendering just uses huge shadow maps (and uses hacks when there are noticable artifacts). Projected shadows are even cheaper and pretty convincing (e.g. Half-Life 2).

Share this post


Link to post
Share on other sites
Hey thanks for the info EvilDecl81...

Man, tbh it seems the more I learn about shadows, the more confusing it gets :) I implemented stencil shadows a couple of days, really naively, and now it turns out it doesn't work on meshes which aren't closed (bummer). So I'm thinking of implementing shadow mapping, though that also seems like quite a can of worms. Lots of texture memory, lots of computations for omnidirectional lights, and horrible aliasing effects if the camera is too close.

So... right now I can either upgrade my stencil shadows code to a better algorithm which handles open or closed meshes, or scrap it and do shadow mapping instead. Right now my stencil shadow code is fairly fast because it does all the work on the GPU- ideally there would be some algorithm that handles non-closed meshes that also utilizes the GPU...

I'm pretty lost right now, I think I'll just start coding shadow mapping for now- even if I can't get it working well, then at least then to say that I learned a new technique. But at some point I do have to commit to some method so that I can get on with my project :) So, if anyone has some recommendation for which route would be the better choice in terms of efficiency and ease of implementation, I would *really* be grateful.

Thanks very much,
roos

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by roos
I implemented stencil shadows a couple of days, really naively, and now it turns out it doesn't work on meshes which aren't closed (bummer). So I'm thinking of implementing shadow mapping, though that also seems like quite a can of worms. Lots of texture memory, lots of computations for omnidirectional lights, and horrible aliasing effects if the camera is too close.

Most shadow volume methods you'll find on the internet require closed meshes, otherwise things go horribly wrong as you've found. The brute force solution would be to cast a volume from each individual triangle but that'll eat your fillrate alive.

Do you *really* need open meshes? I can't really think of many situations where you'd not be able to convert the meshes with a little work.

What kind of typical scene/geometry are you trying to render? Unless you're going for a cutting edge graphics look I'd suggest that traditional methods (varations of lightmaps, projected shadow textures, etc.) would be easier and provide equally good results.

OT.

Share this post


Link to post
Share on other sites

This topic is 4727 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this