I remember having this problem. The solution is extremely simple; if I remember correctly, multiply your hit distance by the cosine of the angle your ray makes with the ray that goes out of the center of the screen.

So, the leftmost ray would be * cos(30) for a 60 degree view, then the next one would be * cos(29.2) or something. You see what I mean?

that might solve the height of the walls issue, but it will introduce other artifacts. its simply not a linear mapping onto your screen.

The cos() method doesnt introduce other artifacts if the angles are derived by projecting. The cos method is *THE* way to remove fisheye in raycasters.

Other artifacts could be introduced if the angles are not derived by projecting. Ie, "for ( angle = -60; angle < 60; angle++)" is BAD

Quote:Original post by Anonymous Poster
The cos() method doesnt introduce other artifacts if the angles are derived by projecting. The cos method is *THE* way to remove fisheye in raycasters.

Other artifacts could be introduced if the angles are not derived by projecting. Ie, "for ( angle = -60; angle < 60; angle++)" is BAD

true, but there is not fisheye issue at all if you do your projections right. come to think of it, i made a mistake myself there. normalizing a ray in rayCASTing will also introduce some kind of warping. the rays on the edge of your screen NEED to be longer than those in the middle. took mysome time to get my head around aswell...

anyway, there is another correct method i realized. if you look closely at the pattern the rays should form (ie a triangular fan), and you realize what the definition of the inverse tangens is again, you should also be able to do it correctly with angles.

Argh, I'm not too happy about drawing anyones attention on these again - but many many years back I wrote some tutorials on raycasting. They seems to still be available here:

http://www.phys.uu.nl/~0307467/scratch/docs/

(Get PxdTut7.zip and PxdTut8.zip)

But please - don't laugh out too loud when you read them :)

- Kasper

Quote:Original post by Eelco

true, but there is not fisheye issue at all if you do your projections right.

You cannot do the projections 'right' in 2D raycasting. Remember that you are only casting rays along the horizon. Points above and below the horizon are what get 'warped' in the fashion known as 'fisheye' as it related to raycasters.

To correctly derive the 'height' of a wall as percieved by a viewer, you multiply what would 'traditionally' be the percieved height of the wall by the cosine of the offset from the center of the view. This corrects for NOT projecting horizontally.

Straight lines become straight again.

The warping caused by using constant angular increments instead of horizon projection is another matter entirely - thats a lateral stretching/bunching effect and although usualy its only a barely noticable effect (for reasonable FOV, although the fact that you can define a 999999 degree FOV should ring bells), there simply isnt any reasonable way at all to compensate besides doing it right to begin with.. the angles are wrong using fixed increments and thats all there is to that.

Quote:Original post by Anonymous Poster

Quote:Original post by Eelco

true, but there is not fisheye issue at all if you do your projections right.

You cannot do the projections 'right' in 2D raycasting. Remember that you are only casting rays along the horizon. Points above and below the horizon are what get 'warped' in the fashion known as 'fisheye' as it related to raycasters.

To correctly derive the 'height' of a wall as percieved by a viewer, you multiply what would 'traditionally' be the percieved height of the wall by the cosine of the offset from the center of the view. This corrects for NOT projecting horizontally.

Straight lines become straight again.

i have never done this, and i had perfectly straight lines. if youre going to normalize your rays, then this cosine correction would correct that. but the more obvious method is to not normalize your rays to begin with. saves you a sqrt and a cos.

Quote:
The warping caused by using constant angular increments instead of horizon projection is another matter entirely - thats a lateral stretching/bunching effect and although usualy its only a barely noticable effect (for reasonable FOV, although the fact that you can define a 999999 degree FOV should ring bells), there simply isnt any reasonable way at all to compensate besides doing it right to begin with.. the angles are wrong using fixed increments and thats all there is to that.

yeah. i dont know how bad the stretching caused by this is, but i imagine it isnt too much for small fovs indeed. yet its fundamentally flawed, and slower: there isnt really any reason to prefer this method.