Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!wuarchive!decwrl!sgi!shinobu!odin!texas.esd.sgi.com!robert
From: robert@texas.esd.sgi.com (Robert Skinner)
Newsgroups: comp.graphics
Subject: Re: A-Buffer source (and plotting lots of triangles)?
Message-ID: <10673@odin.corp.sgi.com>
Date: 20 Jul 90 18:45:28 GMT
References: <1990Jul16.225553.2623@maths.tcd.ie> <1264@idunno.Princeton.EDU> <104 <31667@masscomp.ccur.com> <10588@odin.corp.sgi.com> <31673@masscomp.ccur.com>
Sender: news@odin.corp.sgi.com
Reply-To: robert@sgi.com
Organization: Silicon Graphics Inc., Entry Systems Division
Lines: 74


In article <31673@masscomp.ccur.com>, mark@calvin..westford.ccur.com
(Mark Thompson) writes:
|> In article <10588@odin.corp.sgi.com> I write:
|> >
|> >The Z buffer algorithm can't do transparency.  

I hesitated before making such an absolute statement, because I know 
that people are constantly improving things.

|> 
|> Not necessarily true. If you generate an alpha value for each pixel
|> as well as rgbZ, crude transparency can be implemented still using
|> a standard Z buffer algorithm. This of course begins to fall apart
|> when multiple transparent object overlap (because no linked list
|> of pixel contributions have been maintained). 

ignoring the multiple overlapping transparent objects, tell me what 
happens at a pixel when you have this case:  You have rendered an opaque 
object, then a transparent object in front of it.  I can see how you calculate
the correct color at this point.  Now you render another opaque object
behind the transparent one, you have one of two cases:  

(1) The second
opaque object is behind the the very first one, so its obscured.  The
pixel and Z values don't change.  But how do you know this without
saving an additional Z value for the first obscured object.  

(2) The second opaque object is between the transparent one and the
opaque one.  To compute the correct value of the pixel, you have
to recover the original color of the transparent object, so you have
to save its original color somewhere too.

I just can't see that this works without doing one or more of the
following:

	A:  render objects back-to-front
	B:  save more information at each pixel
	C:  oops, I could have sworn I thought of a third 8^)

Doing A eliminates the render-any-number-of-primitives-in-any-order
advantage of the Z buffer.  Doing B to save just one value doubles the
amount of memory the Z buffer takes, which is already considerable.
If you save much more information, it starts to look like the alpha
buffer.

I would be interested in any references you might have on doing
transparency with the Z buffer.

|> The main reason we used
|> an A buffer in the system I last worked on was to remove edge artifacts
|> on abutting antialiased polygons (using alpha lets the background
|> color seep through the 'cracks'). 

you *want* the color to seep through the cracks?

|> I'm still surprised that your Z buffer
|> was slower.

I've gotten a description of an algorithm that looks faster, but it
will probably be some time before I can look into it or try it.  (Who
knows, maybe I implemented a really fast alpha buffer, and I didn't
realize how fast it really was.)

Robert Skinner
robert@sgi.com

One pill makes you larger, 
 and one pill makes you small,
 and the ones that mother gives you 
 don't do anything at all.
 Go ask Alice when she's ten feet tall. 
 
		-- Jefferson Airplane