Jump to content
  • Advertisement
Sign in to follow this  
Name_Unknown

Inifinite shadow volumes without Carmack's reverse...

This topic is 4751 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

Advertisement
Changing the direction of the depth test is logically equivalent to changing the stencil operation from pass to fail. However, most GPUs will disable hierarchical z-buffering for the rest of the frame if you change the direction of the depth test, so doing that will probably cause a performance hit.

Share this post


Link to post
Share on other sites
Shoot me too if my approach is also already well known. For my shadow volumes (using the big gray square overlay method), I've changed the stencil operation from Compare.Less to Compare.GreaterEqual when rendering the overlay for the case that the camera is in the shadow volume.

This seems to invert the shadow, so it's giving the correct effect, though I haven't implemented a 'camera in shadow check' yet. So maybe a reason for still using Z-fail might be that it is more forgiving on the cam-shadow check, a check which is (as far as I understood) only needed to increase performance by switching to the Z-pass method when possible.

My method would require an exact computation of whether the camera is in shadow or not, but on the other hand it doesn't require capped shadow volumes so the computational expense should be about equal to the Z-fail approach, maybe even faster with optimisations (i.e. only calculating cam-shadow intersection when shadow and/or cam pos changed).

I'm using this technique for my demo, which renders an outdoor scene. For this it seems to be the way to go, since the dimensions of the landscape require a very 'far' far clipping plane, so this is not an issue for my shadow volumes. Maybe this approach is ignored because it just doesn't work well for indoor environment shadows?

Could anyone with some more theoretical background shed some light on this, if it really would work? I just realized I don't even know exactly why the Z-pass algorithm fails when the camera is inside a shadow volume, only that it does.

Share this post


Link to post
Share on other sites
Quote:
Could anyone with some more theoretical background shed some light on this, if it really would work? I just realized I don't even know exactly why the Z-pass algorithm fails when the camera is inside a shadow volume, only that it does.

Shadow volumes make use of the property that, for a closed volume, a ray that intersects the volume will pass through a back facing polygon for every front facing polygon it travels through. An area receiving shadow is where the ray intersects another surface before leaving the volume. Thus, by counting the number of front and back facing polygons between the camera and the shadow receiver, you can calculate which parts, if any, are in shadow.

The z-pass method effectively compares the numbers of front and back facing planes between the camera and the receiver. The receiver is in shadow if they are not equal. Have a look at the diagram from this article and convince yourself that, for any point outside the volume, a ray to any shadowed area passes through only one plane, and a ray to any part outside passes through both a front and back facing plane.

This is no longer the case when the camera enters the volume, and typically the values calculated by the stencil buffer are reversed.

The z-fail method instead counts the number of planes between the shadow receiver and "infinity". Thus it does not matter how many planes lie between the camera and the receiver, so the camera can enter the volume.

Quote:
My method would require an exact computation of whether the camera is in shadow or not

You could still have problems here. There are cases where the volume intersects the viewport, so that half of the screen lies within a volume and half without. This may not be a problem depending on the type of game your engine is designed for, but for a typical FPS you will probably notice the effects.

Share this post


Link to post
Share on other sites
Thanks for the info, MumbleFuzz.

I am only using a directional light (for the sun) and an overview camera for my terrain scene, so the volumes are typically extruded away from the camera with no risk of intersection with the viewport. In fact, I haven't had to use anything else than Z-pass so far and chances are I never will, but I just wanted to check my approach.

I just re-read the topic start however and noticed Name_Unknown's comment that everyone is using shadow maps now-a-days. Is this true? I did some quick reading on shadow maps and the results do look good, but it seems quite an expensive technique and very hard to (efficiently) implement for < SM2 hardware... Would that assumption be correct? :)

Share this post


Link to post
Share on other sites
Shadow maps are becoming popular, but I haven't yet implemented them myself. If done well the visual quality is probably a little higher than using volumes (soft shadows are easier to implement, for example). Depending on your engine requirements, implementing shadow maps well may be harder than implementing shadow volumes, but I think in your case you shouldn't have many problems.

I can't tell you much more than that. For more, I recommend you search the forums for Yann L's comments on shadow maps.

Share this post


Link to post
Share on other sites
Quote:
Original post by Name_Unknown
ok, I see. Thanks Mr. Lengyel ;-)

I realized it was sort of the same idea as reversing it (logically) which is why I tried it... I had this idea that if I did that, well.. it wasn't using the patented algorithm anymore ;-)

I guess not.


Wait... you mean it's literally "patented"? Is that even legally possible? Can you actually patent a shadowing method?

Share this post


Link to post
Share on other sites
Quote:
Original post by Leo_E_49
Wait... you mean it's literally "patented"? Is that even legally possible? Can you actually patent a shadowing method?


yes, creative has patented the zfail shadow-technique, but i wouldn't fear it. first of all, there exist prior art on this, so a sue would proabebly be quite dodgeable. second, a lot of patents are issued to protect yourself from getting sued, not to sue other people.

besides, why would creative, who make gpus that benefit from robust shadows, want to sue a developer for implementing it?

Share this post


Link to post
Share on other sites
I just read an article saying that Creative was going to sue Carmack but they settled it out of court by having Carmack license Creative technology for Doom 3. I might well just avoid using shadow volumes in future...

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!