R18QC@CUNYVM.BITNET (Jeannopoulos Alex) (03/09/91)
Has anyone done any 3d graphics on the AMIGA. I have been some 3D program
ming but I was wondering how I can calculate whether certain lines are removed
ed or should be visible. Any info on hidden line removal would be greatly
appreciated. Thanks
Alex Jeannopoulos
R18QC@CUNYVMkskelm@happy.colorado.edu (03/10/91)
In article <91067.230242R18QC@CUNYVM.BITNET>, Jeannopoulos Alex <R18QC@CUNYVM.BITNET> writes: > Has anyone done any 3d graphics on the AMIGA. I have been some 3D program > ming but I was wondering how I can calculate whether certain lines are removed > ed or should be visible. Any info on hidden line removal would be greatly Well, there's a nifty "clockwise" algorithm for determining if a planar surface is facing the camera. I would *STRONGLY* recommend "Computer Graphics: Princiles and Practice" from the Systems Programming Series, by Foley, van Dam, Feiner, and Hughes (Addison Wesley) It's a 1200 page book that is, IMHO, the bible of graphics. Good luck Kevin Kelm
butch@hoss.unl.edu (Charles Rosecrans Jr.) (03/11/91)
In <91067.230242R18QC@CUNYVM.BITNET> Jeannopoulos Alex <R18QC@CUNYVM.BITNET> writes: > Has anyone done any 3d graphics on the AMIGA. I have been some 3D program >ming but I was wondering how I can calculate whether certain lines are removed >ed or should be visible. Any info on hidden line removal would be greatly >appreciated. Thanks > Alex Jeannopoulos > R18QC@CUNYVM 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). 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. Any help on this would be greatly appreciated. Also, I think someone mentioned a clock-wise algorithm, which works well too. 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. There is really a small difference for a few faces, but when the numbers grow, the normal test gives better time performance. Butch Rosecrans butch at fergvax.unl.edu
reher@ucunix.san.uc.edu (Jay R. Reher) (03/12/91)
I do belive the word you are looking for is Z-buffering. Depth Cueing refers to items looking darker the further they are away from the viewer. My solution to Z-buffering is to enter all polygons into a binary tree , sorting by max depth, the doing a recursive traveral at display time. This does require a lot of stack space and memory , it main disadvantage, but it works well and the display code is easy to write. Jay Reher
rodent@netcom.COM (Ben Discoe) (03/12/91)
butch@hoss.unl.edu (Charles Rosecrans Jr.) writes: > Jeannopoulos Alex <R18QC@CUNYVM.BITNET> writes: >> Has anyone done any 3d graphics on the AMIGA. I have been some 3D program >>ming but I was wondering how I can calculate whether certain lines are removed >>ed or should be visible. Any info on hidden line removal would be greatly >>appreciated. Thanks >> Alex Jeannopoulos >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). I don't use this (backface removal) because I want to be able put the viewpoint INSIDE objects. However, I also don't do shading yet. > 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. I use the Newell,Newell,Sancha (NNS) algorithm from Foley,VanDam etc. Warning! The first edition of this book gave a description of the NNS algorithm that was misleading (actually, just plain wrong.) > Right now I use the minimum Z >value, but this goofs up from time to time. I found that any method (min,max,mid,median...) relying totally on Z would mess up badly a large fraction of the time. NNS has no such trouble but it's a lot slower. In my implementation, NNS is a *lot* slower because although almost everything is integerized, the 3D plane equations used in one phase of NNS are done by converting to floating point, simply because they're fiendishly hard with integers. > Any help on this would be >greatly appreciated. I am looking for people who are working on real-time 3D for the Amiga and are willing to share code/algorithms/ideas. Y'all are welcome to my code. Anyone have a fast triangle clipper/drawer? Currently I do it in C and official Library calls which is rather slow. Anyone have anything in assmbler that might be linked to C? > Also, I think someone mentioned a clock-wise algorithm, which works well >too. 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. Isn't this really the same thing? You're just computing ahead of time, right? >Butch Rosecrans butch at fergvax.unl.edu I also have a decent 3D model editor with a few interesting features. I'd be delighted to share with anyone who could help advance the general cause of real-time, non-commercial 3D on the Amiga. -------------------------- Ben, In San Jose, a horrible city with ignorant destructive uncaring people.
rodent@netcom.COM (Ben Discoe) (03/13/91)
reher@ucunix.san.uc.edu (Jay R. Reher) writes: > I do belive the word you are looking for is Z-buffering. Depth Cueing >refers to items looking darker the further they are away from the viewer. For crying out loud, we're talking Amigas here. Can you imagine doing several frames a second using software Z-buffering? No way. A BSP tree method might certainly do some good (assuming only the viewpoint moves, which is a rather severe assumption). We're talking depth sorting here, not depth cueing (who mentioned cueing?) The Newell-etc. algorithm is the best method I've found after two years of coding, study, and reading every textbook on the subject. If you've got a real suggestion, there are several of us very much interested! >it works well and the display code is easy to write. > Jay Reher ...and takes several minutes for a scene of average complexity, at least. Any ideas for something usable for virtual reality (what we're all interested in nowadays), say, at minimum 1 frame a second? ........Ben, trying to be nice but having sweated blood on this project for a long time, may start to show signs of cracking. Sorry.
rrmorris@uokmax.ecn.uoknor.edu (Rodney Raym Morrison) (03/14/91)
Anyone with good FAST 3d code, --->>> Please send it to me at
rrmorris@uokmax.ecn.uoknor.edu
Thank you, very very much. All code welcomed.valentin@public.BTR.COM (Valentin Pepelea) (03/15/91)
In article <1991Mar14.152912.25591@uokmax.ecn.uoknor.edu> rrmorris@uokmax.ecn.uoknor.edu (Rodney Raym Morrison) writes: > > Anyone with good FAST 3d code, --->>> Please send it to me at > rrmorris@uokmax.ecn.uoknor.edu > > Thank you, very very much. All code welcomed. Me too! Me too! Now seriously, getting a fast 3-d library for free is not to be expected. Dynamix, currently Sierra-Dynamix and soon to be Sierra-Broderbund, has built itself into a 50 people division uniquely out of their 3-d library for the PC. Needless ?Cto say, if you get your hands on an efficient 3-d library, give me a call pronto, and I'll trade you my A1000 for it before you can say 'thief'. Valentin -- "An operating system without virtual memory Name: Valentin Pepelea is an operating system without virtue." Phone: (408) 985-1700 Usenet: mips!btr!valentin - Ancient Inca Proverb Internet: valentin@btr.com
reher@ucunix.san.uc.edu (Jay R. Reher) (03/16/91)
>For crying out loud, we're talking Amigas here. Can you imagine doing >several frames a second using software Z-buffering? No way. A BSP tree >method might certainly do some good (assuming only the viewpoint moves, >which is a rather severe assumption). We're talking depth sorting here, >not depth cueing (who mentioned cueing?) The Newell-etc. algorithm is >the best method I've found after two years of coding, study, and reading >every textbook on the subject. If you've got a real suggestion, there are >several of us very much interested! You obviously didn't read the entire article, and the two previous ones that is spawned from. First of all, Did anyone mention animation ???? NO ! The original post was a beginner in 3D graphics wondering about hidden line removal techniques, not real time animation. Second , The deal with cueing was a terminology mistake that I clarified. I didn't see you clarify anything, or offer how the algorithm that you use works. Third, It was a real suggestion, but since you don't seem to care about the novice graphics programmers, you couldn't see it. >...and takes several minutes for a scene of average complexity, at least. >Any ideas for something usable for virtual reality (what we're all >interested in nowadays), say, at minimum 1 frame a second? Sure it does, I'll bet your algorithm can't do smooth real time animation, except for extremely simple scenes can it ?? As for VR, don't knock my suggestion cause you wanted a VR suggestion. Thats lame, really lame. The best way to do animation that I have used, is to generate each image, then dumptoiff, then make an anim out of it. No it isn't interactive, and it does take some time and patience, but it works for us beginners. >........Ben, trying to be nice but having sweated blood on this project >for a long time, may start to show signs of cracking. Sorry. Since you are cracking we can forgive you, but next time you go looking for VR solution, try sci.virtual-worlds. Jay Reher
butch@fergvax.unl.edu (FERGVAX Daily Operator) (03/18/91)
In comp.sys.amiga.programmer Ben writes: >butch@hoss.unl.edu (Charles Rosecrans Jr.) writes: >> Jeannopoulos Alex <R18QC@CUNYVM.BITNET> writes: >>> [stuff about what Alex wants] >> [stuff about what I do, including calling Depth-Sorting Depth-Cueing >> (thanks for not calling me an idiot as you should have :-=) )] > I don't use this (backface removal) because I want to be able put the >viewpoint INSIDE objects. However, I also don't do shading yet. I've got a byte which I use as flags. There are bits corresponding to rendering (wireframe or solid), lighting (illuminated or one-shade/color), whether or not the face is visible, and whether or not you want the face always visible. With this last bit set, you can throw the viewpoint into the object and let it run. Although before I stuffed 3D clipping into the code, the Guru visited me on several occasions with a few words of wisdom. >> 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. > I use the Newell,Newell,Sancha (NNS) algorithm from Foley,VanDam etc. >Warning! The first edition of this book gave a description of the NNS >algorithm that was misleading (actually, just plain wrong.) I've looked into this and thought maybe it was much too slow for my purposes. Someone else mentioned doing the distance from the center of the face to the viewpoint. This, to me, seems a little more appropriate, but still might give problems. Still, I think there's a better way out there, but I don't know what it is. Of course, my reference point is the commercial products (games especially) which have a specific function and are designed around that. > I am looking for people who are working on real-time 3D for the Amiga >and are willing to share code/algorithms/ideas. Y'all are welcome to >my code. Anyone have a fast triangle clipper/drawer? Currently I do >it in C and official Library calls which is rather slow. Anyone have >anything in assmbler that might be linked to C? On sharing code/algorithms/ideas: This sounds good. I'd be interested as well in doing this. I've got some assembly code for rotations and drawing in 3D which are not very pure at the moment. I'd post them when they're cleaned up, if there's interest. One drawback of the code is the coordinates are limited to short ints. Why? so I could use the hardware multiply and divide instructions. I guess I chose to sacrifice accuracy for speed. On fast triangle clipper/drawer: There was a person who posted a polygon drawer which was optimized for 4 bitplanes. It ran faster than the Amiga's own Area--- routines. I've been working on optimizing it further for 5 bitplanes and EHB mode, but haven't had the time to finish yet. If I've still got the code laying around on my hard drive, I'll post it up here (assuming there's no problem with the person who orinally posted it and the interest exists). Also, I hope to add a clip-while-draw algorithm in the future, which may not be very difficult but I haven't given it a whole lot of thought as of late. >I also have a decent 3D model editor with a few interesting features. >I'd be delighted to share with anyone who could help advance the general >cause of real-time, non-commercial 3D on the Amiga. How about a real-time animation language? I'm thinking about this too. Actually, I'm thinking about a compiler which supports a language to define objects and move them about a 3D world. Anyone else thinking of doing this? I'd be most interested in trading ideas. >-------------------------- >Ben, In San Jose, a horrible city with ignorant destructive uncaring people. Butch butch@fergvax.unl.edu Butch Rosecrans butch@fergvax.unl.edu
rodent@netcom.COM (Ben Discoe) (03/19/91)
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.
int131d@monu3.cc.monash.edu.au (mr s.d. twyford) (03/21/91)
I have been working on 3d vector graphics, trying to develop code that is acceptable for 3d commercial games (it ain't easy). At the moment I have filled polygon graphics with hidden surface removal and depth sorting, but I am still working on window clipping. I have a picture with 80 points and 57 polygons doing 2d rotation, with no polygons moving relative to each other, with one step taking somewhere between 2 and 3 frames in PAL (50hz). For those just begining 3d graphics or those planning to, I suggest that you do what I did. That is, start with a simple program, something that opens an Intuition screen, draws a few lines with Move(); and Draw(); and rotates and redraws until the mouse button is pressed (no double buffering, all real numbers). Then improve it by double buffering, changing all reals to integers, writing assembler drawing routines that use the blitter directly, switching completely to assembler and generating your own copper lists for the screen display. Some people will complain that this is reinventing the wheel, going too close to the hardware, or whatever. I don't see anything wrong with the practice of hitting the hardware as long as you obey the development guidelines in the front of the RKM, and you ask the operating system as politely as possible first, and restore the hardware to the operating system nicely when you exit. If there are any good books on 3d graphics relevent to what I am attempting, I have not found them. Maybe there is one out there somewhere. IMHO the best book on the Amiga display hardware is: The Amiga System Programmer's Guide, Dittrich, Gelfand and Schemmel. No. 6 of the series on the Amiga by Abacus. If anyone knows any good books on writing flight simulators or such, could they please inform me. Now to the algorithms I use in the above mentioned program. I generally grade the efficiency of an algorithm on the number of multiplications and divisions it takes per point or surface or whatever, just as a rough measure. Most surfaces only have one visible side, so I dot a surface normal with a vector from the eye to the surface to detect which side is facing the eye (3d dot product, 3 muls). This is slower than the clockwise method (2 muls), when the surface needs to be drawn, but if the surface is not drawn, and the points are not needed by other surfaces, then the clockwise method requires the 2d perspective of the first 3 points, which takes 6 divs. The surfaces of an object can be grouped into pieces where each surface never overlaps the other surfaces. For example, a cube. The back faces are eliminated by the dot product and the front are all at angles <= 180 degrees. No surface sorting is required, so I group surfaces into these "pieces", relative movements between surface is restricted or the surfaces will start to overlap. I use a binary tree to detect which pieces are behind others, again the pieces are restricted in their movements relative to each other by their places in the tree. To decide which branch of the tree to draw first, I have a surface that is between the pieces on either branch of the tree, all I need is to dot the normal and a point on the surface. Stuart Twyford Internet: int131d.monu3.cc.monash.edu.au
mykes@sega0.SF-Bay.ORG (Mike Schwartz) (03/24/91)
In article <12305@monu1.cc.monash.oz> int131d@monu3.cc.monash.edu.au (mr s.d. twyford) writes: > > If there are any good books on 3d graphics relevent to what I am >attempting, I have not found them. Maybe there is one out there somewhere. >IMHO the best book on the Amiga display hardware is: > The Amiga System Programmer's Guide, Dittrich, Gelfand and Schemmel. >No. 6 of the series on the Amiga by Abacus. If anyone knows any good books >on writing flight simulators or such, could they please inform me. > > Stuart Twyford > Internet: int131d.monu3.cc.monash.edu.au Abacus makes a book on 3-D graphics for the Atari ST. It was written by some german guy and it is all assembler language. It does make use of the Atari ST ROM routines for line drawing and filling, but the Amiga routines should do this faster. mykes -- ******************************************************* * Assembler Language separates the men from the boys. * *******************************************************