Rob Jenkins (robj++at++barney.reading.sgi.com)
Mon, 18 Sep 1995 10:12:40 +0100
I found a previous posting by Angus Dorbie that covers this subject very well:
------------------start of Angus's posting-----------------------
To determine surface visibility the Z value in the framebuffer the
'destination' pixels is compared with the Z of any incoming pixels
being written to because of a polygon surface 'source' pixels.
Typically the pixel value whose Z distance is nearest the eye
(either 'source' or 'destination') determines what ends up being
displayed in the framebuffer.
The snag occurs when you write transparent pixels to the framebuffer.
If you can imagine a scene where you look through smoked glass, you
effectively have a single framebuffer colour, obtained by blending the
pixel in the scene beyond the glass with the colour of the glass, you
also have a single Z value. Unfortunately these values are derived from
two colours and two depth values, both of which are still visible in
the scene.
First we should consider the problem of rendering this simple scene.
If we render the glass first then because of it's nearer Z value it
will occlude pixels from polygons beyond it in the scene. We can avoid
this by disabling the zbuffer write by the glass, in otherwords it has
no Z value and cannot subsequently occlude any polygon pixels. The
problem with this solution is that the glass cannot be blended with
pixels from subsequently rendered polygons (actually it can but this
involves other blendfunctions with their own particular foibles, we'll
keep it simple here). The solution which works is to draw the glass
last and then everything works without any problems. Performer supports
this type of transparency sorting.
e.g.
pfChanTravMode(Pchan, PFTRAV_CULL , PFCULL_VIEW | PFCULL_SORT);
Next we can consider the situation where we've sorted the transparent
stuff and we've rendered the scene and the smoked glass correctly, but
there is another transparent object in the scene which has been sorted
with the smoked glass. If this object is nearer than the smoked glass
it will be drawn correctly, but if it is farther away we are back to
our original problem; either it is occluded by the glass (glass has Z)
or it cannot be partially occluded with the glass (glass has no Z).
Previously we solved this problem by drawing transparent objects after
opaque objects in the scene, we could occlude the transparent with the
opaque and there wasn't a problem. However, here we have to sort
transparent objects by Z distance and draw them back to front to produce
an accurate scene. Performer doesn't automatically support this kind of
transparency sorting. You have to provide it yourself. A quick way to
sort your transparent objects is to build them in the scene sorted and
attach pre and post draw callbacks to a common parent node to stop them
being reshuffled, but this isn't a complete solution (the eye could move!!).
Specific situations like alpha keying such as that used when billboarding
trees can be greatly improved by culling transparent and/or semi-transparent
pixels using ALPHAFUNC and ALPHAREF states.
Under many circumstances if the transparent objects are drawn last without
sorting they will look reasonable if you ensure the transparent objects
don't write to the Z buffer, especially if the alpha values are
low, that is what PFTR_NO_OCCLUDE is for.
So far we've assumed blendfunction parameters of (BF_SA, BF_MSA) but for
layered alpha using the 'destination' alpha value can be of some use in
various circumstances when used in conjunction with the equivalent of
PFTR_NO_OCCLUDE, but it's slow and isn't a generic solution.
Finally there is multisampled transparency, this uses the Reality Engines
ability to store more than one colour and one Z value for each pixel to
avoid some of the pitfalls of blended transparency. The main problem
is that more transparent objects are not visible through more opaque
(if you stick with the same mask) and a limited number of transparency
values are possible due to the small number of samples per pixel,
causing quantisation.
-- Angus Dorbie---------------------------------- end of Angus's posting -----------------
You can get these archives by anonymous ftp from sgigate.sgi.com at:
~ftp/Performer/monthly-archives
the posting above was in perf-95-05
Cheers Rob
-- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. 1530 Arlington Business Park, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj++at++reading.sgi.com,
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:51:53 PDT