Some of your questions are a little unrealistic. A basic understanding of the ray-casting approach would help. A good article would be Whitted''s An Improved Illumination Model for Shaded Display. This was the classic paper which reignited research on ray-casting.

I just thought I''d basically repeat what I posted in the graphics forum here, with small modifications.

Ray-casting was 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.

Ray-casting suffers from aliasing in a horrible sort of way. The simplest way to rectify that is to 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.

Null and Void:

Perhaps you are aware of some obscure usage associated with ray-casting associated with the games mentioned that I am not. But in general, I would like to point out that when discussing ray-casting as known in the computer graphics field, virtually everything you said is exactly the opposite of true. For example, ray-casting or ray-tracing have the following properties:
1) It can do triangles
2) It is used for perspective
3) It is used today, just not in games
4) It is not really fast
5) Is perfect for most lighting effects

Thought i'd add a bit here, because there's more to be said:

Note: bishop_pass, i'm talking specifically about basic raycasting here, not raytracing or any hybrid thereof. I mean 'basic' in the sense of the likes employed by Wolf3D, from a game programming perspective. There, thought i'd get that out of the way .

quote:
What exactly is raycasting? I'm guessing its just lines that all are drawn out from a single point of perspective, and stop when they meet other lines and stuff.

Raycasting is, first and foremost, a method of taking very limited data (say, of your map) and transforming it into a basic world. The reason it can take data as simple as 1s and 0s from a text file is because the world is renderd based on certain geometric constraints (such as orthogonal walls). In essence, you cast a single 'line' for every column outwards, as you thought, but don't necessarily stop when you "meet other lines and stuff". That all depends on how you implement it. Usually you'll have a 2d array which you'll travel through until you hit a "full" cell. Then you'll draw a line there, the height of which being determined by the distance from the camera to the cell. You can work out the formula for the height at any given distance by your field of view, and the size of your walls very easily. Note that you cast a ray per column, not pixel. This is the primary difference between raycasting & raytracing: In 320x200, you'd cast 320 rays in a raycaster. In raytracing, you'd cast (320*200) = 64000 rays.

quote:
But how does it work? What is it coded in, Direct X, or..what?

It works on a very basic level as I explained above... unlike Direct3D, OpenGL and such, it's a very... manual process. You essentially "feel" out your world yourself. The graphics API you use is irrelevant: it is not "coded" in any specific API. The only things you'll be drawing are simple lines, or at the most scaled bitmaps. You could do it in dos, directx, using the windows GDI, whatever, it doesn't matter.

quote:
Is it hard to do?

Hmm, that depends on your skill level . In the grand scheme of things, no. It doesn't take alot of work to get a simple world up and running (but I mean simple), and for such a simple caster all it is is a bit of trigonometry. As long as you know how to use sin(), cos(), tan() and know what an array is, for a very simple caster you'll be fine. Note I am stressing simple, because if you want to make Doom, you're gonna have to do alot more work. Even making doors is a bitch .

quote:
Also, since raycasting is SO FAST, why don't they try to figure out a way to incorporate raycasting with like, OpenGL or something. I mean use raycasting for the entire map and world, then use OpenGL for lighting, effects, etc?

Raycasting isn't "so fast". It *was* fast, back in the good ol' days, but only in the sense of the fastest way to do 3D (be it pseudo or not). Don't let that confuse you into thinking it's a lightning fast method of drawing a fully sophisticated world though. It aint. "they" could implement raycasting into OpenGL I suppose... but, um, then there wouldn't be much for you to program. It's essentailly a whole rendering "engine" in itself. You wouldn't find "them" implementing the trinity engine into OpenGL, because then all we'd have to do is make the bsps .

Null and Void: nitpick here (). You can travel up and down in even the most simple raycaster (crude as it may be). The main constraint about raycasting is the inability to rotate at all on the z-axis. Also, raycasting *is* as adaptable as other techniques - all you have to do is draw a few lines!
Everything else Null and Void said was sound though, so take heed .

Let me know if i've helped, or just made it worse, and good luck!



Insomnia

Edited by - Insomnia on February 20, 2001 7:31:26 AM