 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Ah! Ok, now that you mention it, I suppose I could render the ghosts with
> a shader that puts 1's in the stencil buffer and 0's everywhere else, and
> then use the result to do the post-process step. I never really saw an
> example of using the stencil buffer, but now that you mention it, it's
> entirely likely that's exactly what it was intended for. I'll have to
> study up how you can get a shader to write to it.
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> (Besides, I don't _actually_ know what the stencil buffer is. I just
> assume it does approximately what its name says it does.)
Basically a stencil buffer is a screen-sized buffer in the graphics card's
memory where you can "accumulate" values. For example, you can tell the
GPU "when you draw this triangle, for each pixel of the triangle increment
the equivalent value in the stencil buffer by one". (It's possible to "draw"
triangles to the stencil buffer only, rather than on screen.)
Sounds simple, and it is. It's, however, incredible what kind of uses
it can have. For example dynamic shadowing using shadow volumes uses the
stencil buffer (basically, each shadow volume polygon facing the camera
increases the equivalent stencil buffer values, and each shadow volume
polygon facing away from the camera decreases it, and thus from these
values you get the places on screen which are inside the shadow volumes).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
