Raycasting with walls that are infinitely thin

Raycasting with walls that are infinitely thin

After reading the raycasting information at:

I wonder how the world of this algorithm/example would need to be
modified so that world rule #2:
"Walls are made of cubes that have the same size"

could be changed to be:
"Walls are infinitely thin and can sit between cubes"

Any ideas/suggestions/request for clarification?  I know I've seen
such an algorithm in use before, but all examples for ray casting seem
to dictate the world rule #2 above.  I'd like to find examples on the
'Net that give different rules for the "world" so that I can compare them.

--
+-------------------------------------------+----------------------------+
| T. Gordon Marler                          | LSMSA '85                  |
| Unix System Architect                     | Work: (425) 702-2980       |

+-------------------------------------------+----------------------------+

Raycasting with walls that are infinitely thin

> After reading the raycasting information at:

Hmmm... Looks like the Wolf3D style raycasting

Quote:

> I wonder how the world of this algorithm/example would need to be
> modified so that world rule #2:
>  "Walls are made of cubes that have the same size"

> could be changed to be:
>  "Walls are infinitely thin and can sit between cubes"

> Any ideas/suggestions/request for clarification?  I know I've seen
> such an algorithm in use before, but all examples for ray casting seem
> to dictate the world rule #2 above.  I'd like to find examples on the
> 'Net that give different rules for the "world" so that I can compare them.

Ray casting works by stepping forward along the path of the ray in discrete
steps and checking for intersections at each step. For an infinitely thin
wall, this fails simply because it is extremely easy to miss it i.e. the
previous step before the wall, the next step just after the wall. To solve
this problem, you would decrease the size of the steps ideally infinitely
small. In which case you should just do some line intersection test (or
line-plane intersection, but I'm assuming you're referring to Doom style
walls)

Cheers,

Kai =)

I had constructed a raycasting engine, which works nicely without a
glitch. However, the engine uses floating point for all its
operations. Therefore, I'm now modifying the engine to use fixed point
variables for all its operations. Don't ask why, it's not an option :)

I have my map projected on screen, all with the correct wall size.
Now, here comes the problem. At the four angles, 0, 90, 180, 270
degree, relative to the player, the walls will have jagged edge.
Visually, these few columns of pixels looks like a sound wave, with
middle part protuding out like mad.

Mathematically, the wall height is such that each column does not have
a uniform height. Although I am looking at the same piece of wall,
radically different height numbers are produced.

I am suspecting that by using pre-computed trigonometry tables that
contains fixed point numbers are giving me inaccurate calculations in
wall heights.

I dunno if this is a typical problem for a raycasting engine. If my
theory is correct, how do you suggest I solve that? Or, do you think
it could another thing?

GRex

12. Raycasting