CompuServe Messages

Jez: I also would use matrix math. I was trying to make it simple for Jeric. Too late, though … he's already slithered away in embarrassment, or something. Took a short course some years ago on Computer Graphics, and learned that all the hot dogs use a 4 x 4 matrix approach, so you get the rotation and translation in one step. Assume that's what you mean. Not sure I follow your comments re hidden line removal speeding things up. For skeleton figures, hidden line removal is _THE_ big problem, and lots of papers have been published on the subject. A friend and I came up with a pretty slick way to do it for simple figures, but when you go to arbitrary shapes and multiple bodies, there's really no recourse but to compare every surface with every other surface to see which one's in front. That takes a _LONG_ time, so I fail to understand your comment. BTW, about the same time frame did a little research on the Evans & Sutherland approach ( my company was working on a real-time simulator using same.) Their approach is very clever… it's based on the idea that at any instant of time, the raster point on a CRT represents a single line in space, sweeping across a plane that corresponds to the current raster line. So "all" you have to do is extend this line till it hits some surface. Neat thing about it is: color and shading comes almost free, and the idea of clipping or windowing goes away entirely. The catch: many comparisons to make to find out which surface is hit. E & S do it with mucho parallel hardware, hardwired for the specific algorithm. COme to think of it, the idea fits very well with the Amiga's raster-oriented Blitter control. If you could compute fast enough, perhaps you could compute the next color change _BEFORE_ it has to happen, so the Blitter could be set up for it while the CPU is continuing to compute ahead. It has possibilities. Jack