Re: Alpha and anti-aliasing...

New Message Reply Date view Thread view Subject view Author view

Angus Dorbie (dorbie++at++sgi.com)
Sun, 10 May 1998 13:59:54 -0700

Moshe Nissim wrote:
>
> Angus Dorbie wrote:
>
> > You have the option of using blended transparency instead
> > which will introduce the classic zbuffer alpha occlusion
> > problems unless you sort in the cull process.
> >
>
> Keep in mind that the cull process distance-based sorting is done
> based on the objects' centers of their bounding spheres. On the other
> hand, zbuffer is pixel-based. So this sorting will work correctly
> for some types of scenes, but not for others
> (objects are small compared to inter-object
> distances, no complex depth-interactions between objects, etc.)
> Alas, the classic zbuffer alpha occlusion problem cannot be completely
> solved on zbuffer-based rendering hw.

This is right but not the whole picture, it's appropriate to
supply a little more detail:

The sorting in the cull process places all transparent geometry
(defined as those whose geostate pfTransparency isn't PFTR_OFF),
last in the display list. This isn't a range based test so you
have correct rendering of transparent scene content w.r.t. the
opaque scene.

This leaves you with only inter transparent occlusion, which must
then be depth sorted. This requires the application to modify the
channel bin sorting mechanism using a PFSORT_BACK_TO_FRONT token.
This will produce geoset level depth sorting of transparent objects.

Here from the manual page you can see the calls to set up opaque
geometry sorted by state for performance and the transparent
objects sorted by depth which may cause a few extra state changes.

chan->setBinSort(PFSORT_OPAQUE_BIN, PFSORT_BY_STATE, sortOrders);
chan->setBinSort(PFSORT_TRANSP_BIN, PFSORT_BACK_TO_FRONT, NULL);

This would also explain why turning sorting on might incur a few
extra state changes in some circumstances.

In addition you can then use pfAlphaFunc calls to limit the
scope of incorrect z buffer occlusion on objects like cookiecut
trees.

>
> > You could also use more multisamples to increase the
> > number of multisamples and therefore the number of
> > shades of alpha.
>
> But if you need framebuffer-alpha (not to be confused with
> material/object/texture alpha), don't try to increase the
> number of multisamples.

Few people using performer actually use framebuffer or
destination alpha, and even fewer need to, but with destination
alpha in the visual (RGBA12) you are correct to point out
that on iR only 4 multisample visuals are supported.

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 


For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer++at++sgi.com
        Admin. requests:  info-performer-request++at++sgi.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:57:23 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.