From: Marcin Romaszewicz (marcin++at++sgi.com)
Date: 04/17/2002 11:54:55
On Wed, 17 Apr 2002, Andreas Ekstrand wrote:
> Marcin,
>
> The trees are loaded using the FLT loader. Since the trees are actually
> transparent, I took for granted that PFSTATE_TRANSPARENCY in their
> geostates were set to PFTR_ON and the geosets thereby put in the
> transparent bin by the loader. Perhaps this isn't necessarily true?
The transparency should be enabled by the flt loader. Once that is set,
performer automatically will bin the trees into the transparent bin if you
haven't done so yourself. Do performer-town style trees look ok in your
app? If they do and the crossing quads don't, then back to front sorting
is definitely the problem.
>
> I realize the geoset problem - my trees are for example cross-formed
> quads that probably are being placed in a single geoset by the FLT
> loader and thereby can't be sorted invidually. I've heard about a
> technique called BSP trees - could that possibly be used here? Is there
> any support for BSP in Performer?
Performer doesn't support BSP trees in any meaningful way. BSP trees are
an alternate technique of culling/sorting which allow you to subdivide a
scene such that there are no interpenetrating polygons and everything is
divided into distinct, convex regions. They allow you to have 0 overdraw
and do not require Z buffering to render.
>
> By the way, how does the Infinite Reality multisampling manage to avoid
> this problem?
>
Multisampling is screen-door transparency. You can think of it as
alternate samples being turned on and off on the multisample level. Screen
door transparency is not really transparent, merely a high resolution
"cutout" which is not subject to alpha-blending problems. Since
multisamples are used to fake transparency, MS-transparency can only have
as many distinct levels of transparency as you have multisamples, but in
practice it looks awesome.
-- Marcin
This archive was generated by hypermail 2b29 : Wed Apr 17 2002 - 11:55:07 PDT