"roll" in a raycaster

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.

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:

[attachment=13102:raycastershot.png]

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

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 :)

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.

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.

@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)

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).