Jump to content
  • Advertisement
Sign in to follow this  

What is the stencil buffer?, in Shadow Volumes,..

This topic is 5074 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 recently incorporated shadow volumes to my application based mainly on the nehes example 27. Now I would like to understand what I have done!!. I have the idea that some volumes are renderend on a special buffer called stencil buffer. Could someone explain me what is this buffer? if you could tell me more about different types of buffers,.. I know z buffer of course,.. but stencil buffer???. It will be great if you could give me some short explanation of the technique. PD: I don't understand Nehes explanations very well Regards, /JoseMalo

Share this post

Link to post
Share on other sites

A stencil buffer is like a stencil :-)

either you can draw a pixle or you cant, like when you hold
a paper with a shaped hole(stencil) infront of a airbrush, you will paint
the shape!
simple as that!

Shadow volumes / stencil shadows is a trick, and is just one way to
use the stencil buffer...

By using the zbuffer and the stencilbuffer together, you can determine whatever a pixel will have shadow or not...

When you use the stencil buffer, you first draw regular primitives to the stencilbuffer (witch becomes a black and white picture ) , and then use this as a stencil when you render to your color buffer! simple as that!

How does it work:

If you visualize a shadow volum, you find that if your line of sight goes into the shadowvolum and dont go out, you will see shadow! if it goes into the shadowvolum, and out on the other side you will not se shadow!
So if we put shadow on all lines_of_sight (represented by a pixel) that goes into a shoadow volum, and then erases the ones that goes out again, we should get shadow on the right pixels! By using the zBuffer, we fix so that we cant se stuff behind orher stuff (shadows behind stuff) and the lines_of_sight thats inside the shadowvolum get stopped by the zBuffer, before going out of the volum...

Sum it up:

Render your geometry (to the color buffer and the z buffer)

Draw all front faces of your shadow volums to the stencil buffer (all lines-of-sight going into the shadow volum)

Erase all the back faces of your shadow volums in the stencil buffer (all lines-of-sight going out of your shadow volumes)
(if you invert instead of erase, you can handle intersecting shadow volumes)

Use the stencil you just created to render a black face all over the screen (witch is stenciled, so that only the parts you want get to the color buffer)

BANG, you got stencil shadows

(If you are inside a shadowvolum, you must start by filling the whole stencil buffer, since all lines_of_sight starts inside a shadowvolum)

hope this was to some help!

Share this post

Link to post
Share on other sites
Hello Uncutno.

Sorry for this delay on my reply,.. I was away from the computer,...

Well Your answer is GREAT and VERY CLEAR! Thanks a lots really it was
very helpfull for me.

It is really fantastic to have the oportunity to share knowledge with people here.




Share this post

Link to post
Share on other sites
So stencil shadows a la Doom 3 are not cast onto the world geometry...rather they are projected onto the stencil buffer and used to block out parts of the frame buffer? Have i got it? So much for Carmack's claim to "no more hacks and tricks." :)

Wouldnt this make a stencil buffer 1-bit tho? How come stencil buffer it 8-bit on modern hardware? Is there 256 different levels of transparency?

As for NeHe, I always found his tutes hard to follow, especially with all the Win32 code floating around. I give credit for the effort though.

Share this post

Link to post
Share on other sites
8 bits are required because the same pixel can be behind many shadow casting objects. Each time an object blocks light, the stencil value is incremented. So, when you are finished rendering the shadow volumes, pixels with stencil=0 are rendered, but pixels with stencil > 0 are skipped. So, a 1 bit stencil is not enough.


Share this post

Link to post
Share on other sites
I dont quite get this. *If* the stencil buffer provides a simple frame buffer mask, that either is unmasked (0) or masked (1-255) then i dont see how 8-bits is needed, there is only 2 possibilities. What difference would it matter if multiple stencil shadows overlapped?

Obviously the stencil buffer *is* 8-bit, so I can only guess that its not a simple binary matter of a pixel being masked or not, but there is varing levels of mask.

In Doom 3 stencil shadows can overlap to produce darkers shadows and these stencil shadows certainly dont mask all the pixels within them...its not a simple masked or unmasked thing...

Share this post

Link to post
Share on other sites
about the bits:
as all buffers you can choose its format!
the stencil buffer is 1 bit, but it would
not suprice me if you could set it to 8 or 16,
and do some strange hacks...

but, a stencil (in the real world) is 1 bit! :-) (paper or air)

The problem with stencil shadows is that in one pass, you cant simulate more then one light! (since all shadow pixels have the same color), so a black non-transparent shadow would be casted everywhere not all lights shine! (witch is unrealistic)

DOOM3 solves this by drawing the frame once for each light, and then add(or mul) these renderings toghether: mulit pass rendering!

A little method: if your shadow is non-transparent, you could first clear the buffer, then render the z buffer, then setup the shadow stencil, and then render the scene trough the stencil (opposit to the regular way)
If you got heavy pixelshading, and alot of shadows, you can reduce the number of pixels calculated!(i think doom3 does this)

Last point: Stencil shadows is a hack, and not a solution for the future!
I think you can search these forums for YannL's posts about shadows!

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!