Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!sun-barr!olivea!oliveb!amdahl!netcom!rodent From: rodent@netcom.COM (Ben Discoe) Newsgroups: comp.sys.amiga.programmer Subject: Re: 3D Graphics Message-ID: <1991Mar19.023424.15593@netcom.COM> Date: 19 Mar 91 02:34:24 GMT References: <91067.230242R18QC@CUNYVM.BITNET> <1991Mar10.183032.17717@hoss.unl.edu> Organization: Netcom - Online Communication Services UNIX System {408 241-9760 guest} Lines: 49 billc@cryo.UUCP (William J. Coldwell) writes: >In article <1991Mar10.183032.17717@hoss.unl.edu> butch@hoss.unl.edu (Charles Rosecrans Jr.) writes: >>In my integer-based 3D code, I have a pre-computed surface normal (I use >>this basically for my shading algorithm) that I use. If the Z-element >>of the normal vector is positive after rotation, then the face is pointing >>towards the viewer (or camera). This is backface removal. Doesn't work if you want to be able to move the viewpoint Inside objects. >> So far, this has given me very reliable >>results. Anyone know of a quick algorithm for depth cueing (I think >>thats the word I'm looking for) the faces. Right now I use the minimum Z >>value, but this goofs up from time to time. Depth sorting, the painters algorithm, list-priority schemes. Call 'em what you like. >> Also, I think someone mentioned a clock-wise algorithm, which works well >>too. This is basically backface removal done a different way. Not significant. >> The reason why I choose the normal algorithm is the time it took to >>rotate the normal as opposed to the time it took to derive the value for the >>clock-wise test. Do everthing possible ahead of time. You've got the right idea. >You could use Minimum Z, Maximum Z, Average Z, and center point methods. >A good way for you, would be to use center point method. I've tried all these methods and found that they mess up alarmingly often on even simple scenes. I suggest the Newell-Newell-Sancha algorithm from Foley-VanDam-etc. volume 2. If you don't want to cough up the $65 for the book, I'll be releasing my implementation with source as PD pretty soon. >Find the center of the polygon (avg x,y,z's) find the distance from the >center point to the camera. That's what you use for the sorting. This is an exceedingly bad method for even very simple shapes. True, it's fast, but what's the point of speed when your polygons are in a severly wrong order? In my program, you can move your viewpoint around, switching rendering methods on-the-fly, so you can see just how innacurate the average-Z etc. algorithms are (and how slow the more complex algorithms are :-) ------------- Ben in San Jose: Take my word for it, you don't want to live here.