Ok, this is all theoretical and i came up with it while i was dead tired, so i don''t know if it makes any sense... But I''m gonna go through it anyway. This is very difficult to explain. The viewing volume is shaped like a pyramid with the top cut off (can''t remember the name for this shape right now). Therefore, there are two rectangular faces on this figure, one smaller than the other. Let''s say you divide them both up into grids, say, 1024x768 (using this because it''s a common resolution). Then imagine a line from pixel (1,1) on the smaller rectangle to (1,1) on the larger rectangle. We have a line segment between these two points. If you then determine what objects in the gameworld this line goes through, and then determine which of that set of objects is closest to the viewing plane, you''ve effectively figured out what polygon appears on the screen at that pixel, right?!? RIGHT?!? You could find the exact point in 3d coordinates that would appear on that pixel. It''s beyond my current level of math class taking, but there HAS to be a way to do that. Once you have the polygon it''s on and the coordinates of it, you could determine what texel would appear on it, and then you could determine distance from light sources, objects obscuring light sources, anything... Only problem I could think of is feasibility... For a 1024x768 display as outlined above, you''re doing the above operation for 786,432 pixels per frame. That comes out to about 23,592,960 times per second if you want 30 frames per second (if i tapped it into calculator right). And the operation for each pixel gets more and more complex for every effect you add. But the potential for image quality is simply awesome... Okay people respond, tell me what you think, if you think it could be done or not or whatever... Hi there, I''''m AnCcE, and you''''d be too if you weren''''t somebody else.

Yes, the problem with your idea is the "find what polygons the line intersects". Not only would there be many pixels, but for each pixel you will have to do a complicated search to find which polygons the line intersects. You can either do a very slow linear search (for n = 0 to NumPolygons, test for intersection) or divide the world up into sectors and test those. But it''s much faster to render the polygons as a whole rather than doing that test for each pixel.

You can try it though, and find out for yourself. It shouldn''t take long to realize it''s unfeasible. =)

~CGameProgrammer( );

Yeah, it''s called ray-casting, devised by Appel back in the ''60''s. In ''80, Whitted refined it into ray-tracing. From there, it evolved into Monte Carlo path tracing, cone-tracing, and other such incarnations of the basic concept.

The version you describe suffers from aliasing in a horrible sort of way. The simplest way to rectify that is th trace more rays per pixel. In reality, four to 64 rays are generally traced per pixel. Adaptive super-sampling is usually employed based on heuristics.

In the height of ray-tracing research (the ''80''s), such names as Greenberg, Arvo, Cook, etc. were conducting their test runs on Vax 11/780 mini-computers hooked up to expensive framebuffers. Typical rendering times ranged from one hour to thirty or so hours.

The Amiga, with it''s ability to display 4096 colors while other home computers of the time could only display about 16 or so, made ray-tracing popular with the garage graphics guru. Perhaps it was the rendered animated movie of the ''Juggler'' playing on Amiga monitors which started the whole ''you and me'' can do 3d graphics too craze.

It amazes me that today''s youth, with their hardware accelerated graphics cards, are amazed at rendering times requiring an hour or more. There is nothing wrong with this in the name of research and creating pretty pictures.