Angus Dorbie (dorbie++at++bitch.reading.sgi.com)
Wed, 14 Aug 1996 23:47:02 +0100
This would be faster since you gain _some_ of the performance lost
earlier (as mtj explained) through better sorting, you only need to
guarantee that the stencil is drawn after the base not immediately after,
and you may also be able to save on stencil operation and zbuffer mode
changes since you have the option of sorting by these.
Rgds,
Angus.
On Aug 14, 10:56pm, Angus Dorbie wrote:
> Subject: Re: Flimmering
> If you add my suggestion for writing and testing a new incremented value to
> the stencil planes for each base - decal set then that would solve of the
> problems you've listed below, and probably most others.
>
> The trouble is you need more than a single bit of stencil and you could
> only stack up #stencil_planes^2-1 decal layers before you roll over and risk
> the same problems, probably not a problem
>
> Rgds,
> Angus..
>
>
> On Aug 14, 4:35pm, Steve Baker wrote:
> > Subject: Re: Flimmering
> >
> > Sharon Clay said (of Stencil plane coplanarity):-
> >
> > > The only case where you get into trouble is if a decal overflows
> > > its base because then the base cannot set all of the proper stencil
> > > bits and the base may hit junk set by previous bases. So, decals
> > > must lie completely within their base poygons.
> >
> > ...or the base polygon is translucent and using multisample transparency...
> > in which case there is no guarantee that the base polygon hits all those
> > teeny-tiny subpixels...
> >
> > ...or the case where the daughter polygon lines up exactly along the edge
> > of the host - but teeny-tiny roundoff errors cause the decal polygon to hit
> > a couple of sub-pixels off the edge of the base....
> >
> > Technically, Sharon is correct in that in both of the cases that I list
> > above are properly cases where the decal overflowed the base. But in a
> > practical world of automatically generated or converted databases, I
> > can't guarantee that these kinds of conditions won't sometimes crop up.
> >
> > The problem with this trick is that it looks great on paper but fails in
> > so many practical examples. When it fails, it does not do so gracefully
> > but peppers your display with thin slivers of screwed up mess. What's worse
> > is that a surface very close to your eye can get corrupted by some other
> > polygons twenty miles away behind it.
> >
> >
> >
> > Steve Baker 817-323-1361 (Vox-Lab)
> > Hughes Training Inc. 817-695-8776 (Vox-Office/vMail)
> > 2200 Arlington Downs Road 817-695-4028 (Fax)
> > Arlington, Texas. TX 76005-6171 steve++at++mred.bgm.link.com (eMail)
> >
> > =======================================================================
> > List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
> >-- End of excerpt from Steve Baker
>
>
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>-- End of excerpt from Angus Dorbie
=======================================================================
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:22 PDT