Angus Henderson (angus++at++death.reading.sgi.com)
Thu, 3 Nov 1994 09:32:37 +0000
You leave the z-buffer to work out the drawing order
You have an incorrect blendfunction and/or afunction set
You are using multisampling & your not using msalpha(MSA_MASK)
Here is a Mail that ANgus Dorbie - The Famous Smoke-Meister etc.. sent
me when I strayed from the path of true alpha....
"... this is him speaking now...
On a reality engine there are four methods I would consider for correctly
rendering alpha in a simulation scene. We've already chatted about most of,
the methods, but I'm going to mention them all here anyway.
Each has different characteristics and the desired effect must be
considered before deciding on a method. Fortunately most methods are
implemented
with mode changes so it's easy to experiment. I'm assuming blending has been
enabled with:
blendfunction(BF_SA, BF_MSA);
1) The first method is issuing the command
AFUNCTION(value, AF_GREATER);
DESCRIPTION:
Here only source pixels with alpha values greater than 'value' will contribute
to the frame buffer.
ADVANTAGES:
This is usefull when rendering trees and assorted sub-aquatic life since it can
be used to prevent transparent and semi-transparent pixels contributing to the
frame buffer and therefore occulting other objects behind the transparent
polygon boundary.
PROBLEMS/SOLUTIONS:
This method simply doesn't work for semi-transparent textures requiring
the drawing order to be depth dependant; a depth sort is still required.
If this is not performed the typical symptoms are an intermittent
halo around the tree or fish being rendered using alpha texture. This is caused
where the value in AFUNCTION is too low (and it has to be or semi-transparent
pixels will be culled) and so will not be drawn. You could turn the value up to
254 eliminating all transparency but then you see sharp texel boundaries when
viewing at close range, even if you ar applying a bilinear MAXFILTER. You will
also see a lot of aliasing and temporal aliasing since polygons are only
multisampled at their boundaries, semi transparency softens the edges and makes
it less obvious.
2) Alternatively you can issue the command
zwritemask(0x00000000);
DESCRIPTION:
This method prevents alpha pixels (and all other pixels) drawn from
contributing
to the zbuffer threfore they don't occult pixels drawn later and deeper in the
framebuffer.
ADVANTAGES:
This method allows all values of alpha to smoothly contribute to the
framebuffer
and still allows them to be occulted by other objects in the scene. This is
one method which would solve the Paradigm smoke trail problem where the
previous method could only improve it.
PROBLEMS/SOLUTIONS:
The transparency method detailed here will only work if the alpha is drawn
last in the display list, although it doesn't have to be depth sorted with the
scene contents. If this is not done then scene contents will occult the
transparent effects reguardless of depth simply because theyre not in the
zbuffer. The reverse doesn't happen because the scene is in the zbuffer and the
zbuffer testing is still on. Another problem exists here, that is distant
transparent objects occulting transparency in the forefround, this is at it's
most noticable when the foreground alpha is almost opaque. The problem here
is we don't have a zbuffer test for alpha so we have to depth sort (alpha
only).
This generally only required between groups of alpha polygons: depth sort the
fires in a scene rather than every smoke polygon in a fire.
3) This brings me to the third method:
DESCRIPTION:
Simply draw all alpha polygons in the order they appear from the distance to
the
eye. Additionally alpha should be drawn after the rest of the scend as with the
above method.
ADVANTAGES:
No mode changes are required. This works well with things like billboards
provided they don't overlap in 3D and are drawn last. Depth ordering the fish
in the demo is probably better than using any mode changes if you can avoid
them overlapping(in 3D).
PROBLEMS/SOLUTIONS:
Unless you depth sort all alpha polygons alpha pixels will occult each other
leaving sharp edges within an effect. Overlapping polygons can't be depth
sorted
so where a tree has been modelled as two crossing polygonss with alpha texture
this method is unsuitable.
4) All of the above techniques can be used on other SGI graphics options,
although the afunction may be limited to VGX & VGXT, the fourth thechnique is
exclusive to the reality engine and employs its multi-sample buffer, issue the
commands:
msalpha(MSA_MASK);
blendfunction(BF_ONE, BF_ZERO); /* turn alpha blending off !! */
DESCRIPTION:
Alpha is now contributing using a subpixel mask to produce transparency in the
displayed framebuffer.
ADVANTAGES:
There is no need to depth sort or draw the alpha polys last since subpixel
framebuffer values are individually compared and are either on or off even
where
transparency has been contributed to a pixel. This method is great for trees
shoals of fish and other billboards. This method is also compatible
with those above and so can be used in conjunction with method 2, I've
mentioned
this because it's probably the only other method you'll actually use on a
reality engine.
PROBLEMS/SOLUTIONS:
Due to the limited number of sub-pixels per pixel on a reality engine only a
limited number of transparent values can be represented by a sub-pixel mask.
This isn't a major problem when rendering a tree but when rendering a smoke
effect for example the smooth alpha values on the polygon will be quantized
producing a contoured effect. Additionally the application of transparency
isn't
cumulative since it's only a mask which is being used to determine
contribution.
There are a number of related side-effects produced by using the MSA_MASK mode.
The easiest way to understand them is to imagine using the defpattern and
setpattern commands, only it's being done dynamically by dithering using the
alpha value at a sub-pixel level.
I hope there's something in here which is new. Either way have fun (if it's
possible to have more than you already are).
-- _______________________________________________________________________________Angus Dorbie (0454)615554 Software Engineer angus++at++division.demon.co.uk _______________________________________________________________________________
...he's finished now and it's ANgus Henderson again"
As you can see he was helping me with fish in that case but fish and trees are one and the same to me.
By the way I've just copied the fish demo - all 7 Megabytes -
to sgigate.sgi.com:~ftp/pub/Performer/RealityCentre
ANgus
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:38 PDT