scott wrote:
> The problem is reading from it, AFAIK you can't read from the stencil 
> buffer in a pixel shader on most hardware, all you can do is tell the 
> GPU to run your shader or not, depending on certain criteria of the 
> stencil buffer.

Ah, OK. That shouldn't be a problem here, tho, because I want to run the 
ghost's pixel shader where the ghost is and not where he isn't, without any 
additional decisions. :-)

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

Warp wrote:
>  It's, however, incredible what kind of uses
> it can have. For example dynamic shadowing 

Do you have any good bookmarks for that sort of stuff? Or am I off to google 
to try to guess which is best to study? :-)

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >  It's, however, incredible what kind of uses
> > it can have. For example dynamic shadowing 

> Do you have any good bookmarks for that sort of stuff? Or am I off to google 
> to try to guess which is best to study? :-)

  Not really, but you could try: http://nehe.gamedev.net/

-- 
                                                          - Warp

Post a reply to this message

scott wrote:
> 1. Set render target to temporary one
> 2. Render scene without ghost normally, but set stencil writes to always 0
> 3. Render ghost geometry without writes to RGBA, but stencil write of 
> always 1
> 4. Switch the render target to the actual back buffer
> 5. Render a full-screen quad to simply copy over the entire temp buffer 
> RGBA contents
> 5. Set your special effect pixel shader
> 6. Set stencil pass function to equal 1
> 7. Render a full-screen quad at the depth of the ghost (this will avoid 
> affecting anything infront of the ghost)
> 8. Render the ghost normally

I was following you up until 7. First, since the ghost is a model, I'm not 
sure what the single "depth" would be. But OK, assuming I'm not actually 
intersecting geometries with the ghost, I can work with that.  However, 
doesn't step 5 destroy the original depth information? That was the step I 
couldn't figure out how to get around. If I've turned the 3D models and such 
into a flat quad, I've lost the original depth information there.

Secondly, I'm not sure what 7 is for at all. Maybe you're thinking something 
different for "render ghost" than I am? Does step 8 mean "render the parts 
of the ghost you can't see through" or something?  Do you mean that 7 will 
combine the stencil buffer with the depth buffer somehow? Wouldn't the 
stencil buffer already be 0 where there's something occluding the ghost?

> Sure, if you write depth on purpose to a special render target, what is 
> not normally available is the "internal" depth/stencil buffer that the 
> GPU uses to do depth and stencil tests during normal rendering.  So 
> you're usually having to duplicate the depth buffer if you want to use 
> it in a non-standard way.

True. I think keeping two copies of the depth buffer is less overhead than 
rendering all the geometry twice, tho.  That's really the bit I'm trying to 
avoid.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>>  It's, however, incredible what kind of uses
>>> it can have. For example dynamic shadowing 
> 
>> Do you have any good bookmarks for that sort of stuff? Or am I off to google 
>> to try to guess which is best to study? :-)
> 
>   Not really, but you could try: http://nehe.gamedev.net/

The TOC looks interesting. Thanks!

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

Warp wrote:
> dynamic shadowing using shadow volumes 

I pretty much follow *how* that works, but I'm not sure why you would do 
that over doing it some other way. It would seem that calculating the shadow 
volumes is something relatively compute-intensive for something moving.

Is it a trade-off between computing the volumes and then being able to just 
render things essentially once, rather than rendering the whole scene from 
the POV of multiple lights or something?

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > dynamic shadowing using shadow volumes 

> I pretty much follow *how* that works, but I'm not sure why you would do 
> that over doing it some other way. It would seem that calculating the shadow 
> volumes is something relatively compute-intensive for something moving.

  There are two competing algorithms for rendering real-time dynamic shadows
with current graphics hardware: Shadow volumes and shadow mapping. They use
completely different approaches to achieve the same (well, similar) result.

  As you might guess, there's no "better" algorithm. It's always about
compromises. One algorithm is better at some things and worse at others.

  Shadow volumes allow rendering pixel-perfect shadows (in fact, even
sub-pixel-perfect if you are using antialiasing). This accuracy is
completely independent of the distance between the shadowed area to
the shadowing object or to the light source causing the shadow. It also
requires less RAM (the shadow polygons are numerous, but polygons are
quite memory-light compared to bitmaps; the only other memory needed is
the stencil buffer.)

  The disadvantage of shadow volumes is that they are considerably more
complicated to implement, and their speed is heavily dependent on the
geometry of the scene. (Also soft shadows are not possible with the
basic algorithm, although I have heard of an expanded algorithm which
would support soft shadows, probably at the cost of rendering speed.)

  Shadow mapping is easier to implement and often (although not always)
faster. Its problem is that it you always have to make a compromise between
accuracy and memory usage (the larger the shadow maps, the more accurate
the result, but the more RAM is required; more accuracy might also affect
rendering speed by some amount). Also, the accuracy is heavily dependent
on the distance between the surface being shadowed and the shadowing surface
as well as the light source (the larger the distance, the blockier and
less realistic the shadow becomes).

  Shadow mapping has also another advantage over shadow volumes: Certain
shadowing effects are extremely light to do with shadow maps because they
require no rendering at all (to get the shadows), while with shadow volumes
you would need to run the full shadow-polygon-creation-and-rendering process
to get the same effect. For example, if you want a moth flying near a lamp,
you can "cheat" and add the moth's shadow to the correspondent shadow maps
algorithmically (instead of rendering the moth with the GPU as usual), and
thus even complex such shadows take virtually no rendering time.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   As you might guess, there's no "better" algorithm. It's always about
> compromises. One algorithm is better at some things and worse at others.

Thank you for the detailed explanation. I figured the algorithms had 
different strengths, but I couldn't figure out just from understanding the 
basics of the algorithms what the strengths were.

>   Shadow mapping is easier to implement and often (although not always)
> faster. Its problem is that it you always have to make a compromise between
> accuracy and memory usage (the larger the shadow maps, the more accurate
> the result, but the more RAM is required; more accuracy might also affect
> rendering speed by some amount). 

Huh. I always wondered why old games had very pixelated jaggy shadows, but 
now that you mention it, if you do the shadow projection on a very small 
depth buffer, that's just what you'd expect. Cool.

> you can "cheat" and add the moth's shadow to the correspondent shadow maps

Yeah, I can see that.

XNA even has a constructor for the Matrix class where you give it a point 
and a plane, and it constructs a transform that maps a point to where it 
would cast a shadow onto that plane. I guess that's exceedingly fast as long 
as you're only casting shadows onto flat surfaces, like running across 
simple terrain or inside a corridor or something.

Now, if only I could get inspired to actually sit down and work on my next 
game, I'd be good. :-)

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

>> 1. Set render target to temporary one
>> 2. Render scene without ghost normally, but set stencil writes to always 
>> 0
>> 3. Render ghost geometry without writes to RGBA, but stencil write of 
>> always 1
>> 4. Switch the render target to the actual back buffer
>> 5. Render a full-screen quad to simply copy over the entire temp buffer 
>> RGBA contents
>> 5. Set your special effect pixel shader
>> 6. Set stencil pass function to equal 1
>> 7. Render a full-screen quad at the depth of the ghost (this will avoid 
>> affecting anything infront of the ghost)
>> 8. Render the ghost normally
>
> I was following you up until 7. First, since the ghost is a model, I'm not 
> sure what the single "depth" would be.

If you wanted everything behind the ghost in the scene to be affected, then 
I would set the "depth" to the furthest away point of the model (but maybe 
experiemtn, I don't know how much of an effect it would have with 
intersecting geometry).

> But OK, assuming I'm not actually intersecting geometries with the ghost, 
> I can work with that.  However, doesn't step 5 destroy the original depth 
> information?

No, you should be able to control the RGBA render target and the 
depth/stencil target separately.  In DirectX you call 
SetDepthStencilSurface.  For my algorithm I assumed a single Depth/Stencil 
surface would be persistent throughout the whole process,

> Secondly, I'm not sure what 7 is for at all.

It applies the shader as you requested here: "Basically, I want to apply a 
screen-space shader but only to parts of the
scene occluded by a model which is in turn partially occluded by other parts
of the scene."

> Does step 8 mean "render the parts of the ghost you can't see through" or 
> something?

I assume your actual ghost model has varying levels of transparency, 
otherwise there would be no point in applying some shader to the scene 
behind it.  Step 8 means render the ghost as normal - of course the 
background will already be distorted somehow due to Step 7.

Post a reply to this message

scott wrote:
> No, you should be able to control the RGBA render target and the 
> depth/stencil target separately. 

Oh, I see. OK.

> I assume your actual ghost model has varying levels of transparency, 

In my imagination, it was totally transparent. Hence the subject line. But 
OK, I see what you're saying here.

Again, thanks for the help!  Seems what I was missing was the stencil buffer.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message