Re: Flimmering
Angus Dorbie (dorbie++at++bitch.reading.sgi.com)
Wed, 14 Aug 1996 18:01:14 +0100
On Aug 14, 8:52am, Michael Jones wrote:
> Subject: re: Flimmering
> Angus Dorbie wrote:
>
> > So how do you erase the stencil information when you are done? (the extra
pass)
>
> You don't erase it. You don't care what's in the stencil planes unless
> you have enabled stencil mode, and you only do that as you are rendering
> a new set of coplanar layers, the first of which (the base) writes to
> the stencil planes. By the time the frame's complete, there is probably
> a bunch of junk in the stencil planes, but you don't care.
>
> >Your approach will only work if you don't have any occlusion between
> >decal surfaces, or if you depth sort.
>
> Not so. I must have explained poorly, as stencil-based coplanarity is
> the deluxe mode and always works perfectly. Here are the rules for
> Performer layer nodes:
>
> 1. an arbitrary set of coplanar base polygons.
>
> 2. a set of first-layer-above-the-base polygons that are
> coplanar with those in step #1, and are contained within
> the boundary of the polygons in step #1. For example, if
> #1 is the runway, #2 is the stripes and they cannot extend
> off the runway -- they are paint and can only go where the
> base layer is.
>
> 3 - N, layers just like #2, that have increasing visual
> priority. If they were painted, they would be painted in
> order: 1, 2, 3, ..., N.
>
> Now, to render this ensemble using stencil-planes, the following
> approach does the job without error:
>
> a. enable "set stencil based on depth-compare pass/fail" mode
>
> b. render the base layer (#1)
>
> [note that at this point all of the pixels (subpixels on re/ir) in
> the area covered by #1 have a stencil bit that means: 1==visible,
> 0==invisible]
>
> c. disable depth comparisons.
>
> d. disable stencil updates.
>
> e. enable "only draw where stencil == 1" mode.
>
> f. render layer #2.
>
> [note that since layer #2 is coplanar with #1, and since it is "inside"
> the area of #1, the pixel writing can not touch any pixel or sub-pixel
> not visited in step "b", thus the stencil bits are a valid guide to the
> visibility of this layer.]
>
> g. loop through the remaining layers and render them like step "f".
>
> [note that the pfLayer (or pfDecal) ensemble is now correctly rendered]
>
> h. disable stencil comparisons.
>
> i. enable depth comparisons.
>
> j. continue with drawing.
>
> This does work well without exception.
Your first explanation was fine, it was my explanation which wasn't clear.
I understood this, agreed this will work for one set of base polygons
the point I was making was that for a truly robust decal operation you
need a second pass on the base to erase stencil unless you depth sort your
bases.
In the scenario below the decal2 will show through base1 & decal1 if you
draw base1 & decal1 first. This is what I meant by "occlusion between
decal surfaces", I didn't mean decals on the same base.
Eye decal1 & Base1 decal2 & Base2
| |
| ||
| ||
<) || ||
|| |
| |
| |
With one stencil bit this problem is unavoidable.
This wouldn't be a problem if you have more that 1 stencil plane because
by changing operations b and e where you render and test against a stencil
value which increases with each base & layer set.
To avoid confusion, I don't mean a stencil increment operation, just
increment the write and test value for each decal & base set.
Rgds,
Angus.
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2
on Mon Aug 10 1998 - 17:53:21 PDT