• Create Account

## "roll" in a raycaster

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

6 replies to this topic

### #1ic0de  Members

955
Like
0Likes
Like

Posted 05 January 2013 - 11:35 AM

I'm developing a raycaster similar to that used in NovaLogic games like Comanche but this applies to raycasters in general. How did nova display the roll of the helicopter? I came up with an algorithm that takes yaw and pitch into account but not roll. This is my perspective calculation:

perspectiveHeight = ((height + cameraheight) / raylength * viewPlaneDist - pitch);

The yaw is done easily by rotating the rays that are cast into the scene and the pitch is added into this equation. Like Doom and Wolfenstein 3D my raycaster is technically two dimensional so I cannot simply rotate my rays to induce roll. The only way I could think of is literally rotating the final image but I would need to cast rays outside the scene for that. How was it Done in Comanche? How did other games do it? Any input would be much appreciated.

you know you program too much when you start ending sentences with semicolons;

### #2Lightness1024  Members

920
Like
0Likes
Like

Posted 05 January 2013 - 10:27 PM

Well I doubt a game like comanche uses 2d marching. to obtain pitch yaw and roll you must pass 3D rays through a view camera matrix. the original rays always point towards Z and then the view camera matrix represents the helicopter orientation and position as well if it is 4x4.

### #3ic0de  Members

955
Like
1Likes
Like

Posted 05 January 2013 - 10:41 PM

Well I doubt a game like comanche uses 2d marching. to obtain pitch yaw and roll you must pass 3D rays through a view camera matrix. the original rays always point towards Z and then the view camera matrix represents the helicopter orientation and position as well if it is 4x4.

I wouldn't be suprised if comanche did use 2d rays. I've achieved amazing results with it, I only need to cast as many rays as there are columns of pixels. I'm not gonna change the algorithm completely just so that I can roll the camera. If absolutely necessary I'll just rotate the final image. Anyway here's a screenshot of my raycaster (using a map from comanche) just to show how viable the approach is:

anyways does anyone know how to do this in a 2.5D raycaster like wolfenstein?

you know you program too much when you start ending sentences with semicolons;

### #4Krypt0n  Members

4529
Like
2Likes
Like

Posted 06 January 2013 - 09:29 AM

it looks like they just sheered the view slightly in comanche, not really rotation, but in those little angles it looks ok'ish. so you just offset the y starting point in your raycaster. simple and effective for back then

### #5Lightness1024  Members

920
Like
0Likes
Like

Posted 06 January 2013 - 09:56 AM

So I just don't understand anything about how the rendering is done with your technique then. one ray per column ? how do you fill the column then, does not one ray = one pixel ? Do you have some kind of "ray to heightmap" intersection routine to render the terrain ? (like dichotomy or cone-based...?)

what is 2d, the scanning or the actual ray information ?

(I mean, a 3d ray bears 2 vectors of 3 scalars, a starting point and a direction, so your 2d rays stores what ? an origin pixel and a 2d direction ?)

about sheering, if a rotation were to be "simulated" by sheering my eyes would surely bleed. Can you just not do a space trick that would effectively make the rotation ?

Like when you create your rays, you trick the ray creation from the original data by rotating your origin space ? (if the pixels are your origin space when you scan the columns, then after extracting the coordinates (eg from loop indices), for your pixel, you just rotate them in place, and the following calculations will be space-tricked.)

edit: from this article https://en.wikipedia.org/wiki/Ray_casting, I start to vaguely see what was I missing in my mental conception of what you called ray casting. the folling of columns seems to be kind of retro-fed from the highest pixel, instead of casting one ray per pixel. But that seems very specific to games that will have only one or two objects to draw per column. And the terrain case actually seems very complex. If I believe my knowledge of how shadowing is done in parallax occlusion mapping, then its a quite involved algorithm and I fail to see how this could run real time. There must be something I am missing about heightmap rendering techniques. I feel this something must lay near the 2d-thingie concept that I can't quite grasp as well. Rotations would be obvious with 3d rays, and would not even deserve a question here, therefore my very simple first answer about the view matrix.

Edited by Lightness1024, 06 January 2013 - 10:05 AM.

### #6ginkgo  Members

298
Like
0Likes
Like

Posted 06 January 2013 - 01:42 PM

Might it be possible to do raycasting along vertical lines but then setting the resulting pixels along diagonal lines using Bresenham's algorithm?

The Bresenham pattern would be the same for all lines, so there should be no holes. It could also be stored and reused. The angle of the lines should be the inverse of the actual roll. You also need a height offset, otherwise you just get a skewed image. I guess there might be some artifacts due to the Aliasing in the Bresenham, but that should be acceptable.

### #7Krypt0n  Members

4529
Like
3Likes
Like

Posted 07 January 2013 - 10:03 AM

@Lightness1024

that oldschool raycasting relies on the idea that you trace along a heightmap.

you start in every column on the bottom most pixel x0|y0 and trace it to the point where you hit the ground. at this moment you know, because it's a heightmap/terrain, every pixel in that column is at least traveling that far, so you offset the current ray, as if it was shoot from x0|y1 (which means you just adjust the current height value, you are at the same place of the heightmap), and you progress with the tracing/sampling of the heightmap. till you hit the ground again etc etc etc.

another way to think of it is, if you'd draw the rays for every pixel of column x0 on the heightmap, you would just see one line, because they all overlap.

So the only thing that really changes is just the height and at every step of the lines you can assume

LineHeight(x0,y0,Step)<=LineHeight(x0,y1,Step)<=LineHeight(x0,y2,Step)<=LineHeight(x0,y3,Step)<=LineHeight(x0,y4,Step)<=LineHeight(x0,y5,Step)<=LineHeight(x0,y6,Step)....

now you know, if HeightmapSample(x0,y0,Step)<LineHeight(x0,y0,Step)

then HeightmapSample(x0,y...,Step) is smaller then all the other lines, as their height MUST be above the lowest line.

if you Hit the ground with the lowest line, you are done with it, you get the color of the terrain texture at that place and you place set it to the screen and you now progress with the line above till it hits the ground as you still know, if it doesn't, all lines above wouldn't.

and that's all the reason why 'rotating' wouldn't really fit into the idea. you would actually create none-overlapping rays per column. the problem is, it might be the case, that while the lowest line does not hit the ground yet, the line above, which is slightly rotated, would hit might hit the ground, as it samples next to the current heightmap sample.

I think a sheering won't make ur eyes bleed if you survived voxel raycaster, they are allready full of cheats, the perspective isn't that accurate (in exchange for speed) and the accuracy is often also not the best (and most of them also miss filtering).

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.