Path: utzoo!attcan!uunet!lll-winken!uwm.edu!rpi!masscomp!calvin!mark From: mark@calvin..westford.ccur.com (Mark Thompson) Newsgroups: comp.graphics Subject: Re: A-Buffer source (and plotting lots of triangles)? Message-ID: <31673@masscomp.ccur.com> Date: 20 Jul 90 15:22:24 GMT References: <1990Jul16.225553.2623@maths.tcd.ie> <1264@idunno.Princeton.EDU> <104 <31667@masscomp.ccur.com> <10588@odin.corp.sgi.com> Sender: news@masscomp.ccur.com Reply-To: mark@calvin.westford.ccur.com (Mark Thompson) Organization: Concurrent Computer Corp. Westford MA. Lines: 28 In article <10588@odin.corp.sgi.com> robert@sgi.com writes: > >In article <31667@masscomp.ccur.com>, mark@masscomp.ccur.com (Mark >Thompson) writes: >|> I'll bet those images weren't identical when rendering piles of >|> overlaping partially transparent objects! > >right, I didn't bother to implement transparency, because I didn't >need it, and I didn't know if I would end up using the Z buffer. > >The Z buffer algorithm can't do transparency. >I stopped just short of stating (what I thought) was obvious. 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). 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'). I'm still surprised that your Z buffer was slower. +--------------------------------------------------------------------------+ | Mark Thompson | | mark@westford.ccur.com | | ...!{decvax,uunet}!masscomp!mark Designing high performance graphics | | (508)392-2480 engines today for a better tomorrow. | +------------------------------------------------------------------------- +