Message-ID: <D1FB30BBA491D1118E6D006097BCAE3923B8DD@Probe-nt-2a.Probe.co.uk>
From: Shawn Hargreaves <ShawnH AT Probe DOT co DOT uk>
To: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Cc: djgpp AT delorie DOT com
Subject: RE: What is Z-sorting?
Date: Wed, 8 Apr 1998 16:13:24 +0100
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

> Hans-Bernhard Broeker writes:
	> Isn't it funny how many interpretations such a seemingly
innocent
	> question can have? 

This is the bane of any discussion about graphics coding: the same 
handful of jargon terms gets endlessly recycled (or misused) to mean 
totally different things :-)

	> Just for the sake of correctness: this isn't the whole truth
on
	> depth-sorting. Actually, you *can* make depth-sorting correct,

	> it just takes a bit more effort to get it right (been there,
done 
	> that). Take Quake, as an example: AFAIK some of it uses
BSP-trees, 
	> which can be viewed just as a clever approach to
depth-sorting.

True, although you could argue that this is no longer simply "sorting",
because it requires some polygons to be split or clipped. You have
to actually change the geometry, and sometimes create new polygons,
rather than simply moving them into a suitable order.

	> BTW: To make the difference between the 'naive' implementation

	> and full-fledged depth-sorting clear, the naive one is often 
	> called 'painter's algorithm', instead.

That is certainly a better term.

	> I have to raise a small objection to this: zbuffer is not
'100%'
	> accurate.  It's exactly as accurate as the the pixel
resolution 
	> you happen to apply it to.

Yeah, 16 bit zbuffers are annoying. But a 32 bit floating point 
implementation is accurate enough for just about anything, and the
algorithm is theoretically correct: these are just implementation
details that can introduce errors...


	Shawn Hargreaves