## Tinytut for voxel tunnel

**category:**code [glöplog]

In the midst of the 90's a french group called Nooon released a DOS-demo called Stars: Wonders of the World that featured a voxel tunnel. It came at 1st place at the Assembly 1995 demo-competition.

With the help of polar-coordinates and raytracing we can visualize the voxel-tunnel effect. From what I can remember this effect was rarely shown in demos, which I do not know the reason for, other than that it is an impressive effect to watch.

For every point (in cartesian coordinates) we want to know its polar equivalence: (radius and theta). We should computing these points and store them in a lookup-table for fast access (there might be other methods). It is easy to find the length (radius) from the center of the screen to the polar-point. The radius is the hypothenuse of a right-angled triangle. Remember to compute it from the center of the screen. Thus, we take the "squareroot of x-squared pluss y-squared" and then we have the radius.

Finding the theta-angle is a little more tricker, but if you paid attention in your trigonometry class you should remember that it has something to do with sine and cosine. We don't even need to know the length of the hypothenuse to compute the angle because we can use arctangent (the inverse of tangent). With the arctangent we use the relationship between the x and y coordinate: Now we have our table.

The rendering part is very simple and is as follows: Visit all points in cartesian-coordinates (with our screenbuffer), lookup the radius and angle, compute the color for our voxel by raycasting inside a texture. This is done much like a voxel-landscape, depending on wether you interpolate (linear, cubic) or not you start with the lowest radius and increase it until it reaches the the end of the screenbuffer, then go to the next angle and repeat. The radius and angle is basically compressed to byte or word (8 or 16-bits) while this is done we use an alpha-interpolator for interpolation or just read the color from the texture. This can be done by shooting a ray with whatever fov (field of view) you like.

This was a quick and dirty tut for making voxel tunnel. Just a few adjustments can make this work for blobs too by changing some of the lookup buffers, but leave that as an excersize for the reader.

With the help of polar-coordinates and raytracing we can visualize the voxel-tunnel effect. From what I can remember this effect was rarely shown in demos, which I do not know the reason for, other than that it is an impressive effect to watch.

For every point (in cartesian coordinates) we want to know its polar equivalence: (radius and theta). We should computing these points and store them in a lookup-table for fast access (there might be other methods). It is easy to find the length (radius) from the center of the screen to the polar-point. The radius is the hypothenuse of a right-angled triangle. Remember to compute it from the center of the screen. Thus, we take the "squareroot of x-squared pluss y-squared" and then we have the radius.

**Code:**

`radi = sqrt(x*x+y*y)`

**Code:**

`arctan(y/x) = theta`

The rendering part is very simple and is as follows: Visit all points in cartesian-coordinates (with our screenbuffer), lookup the radius and angle, compute the color for our voxel by raycasting inside a texture. This is done much like a voxel-landscape, depending on wether you interpolate (linear, cubic) or not you start with the lowest radius and increase it until it reaches the the end of the screenbuffer, then go to the next angle and repeat. The radius and angle is basically compressed to byte or word (8 or 16-bits) while this is done we use an alpha-interpolator for interpolation or just read the color from the texture. This can be done by shooting a ray with whatever fov (field of view) you like.

This was a quick and dirty tut for making voxel tunnel. Just a few adjustments can make this work for blobs too by changing some of the lookup buffers, but leave that as an excersize for the reader.

*Indeed this tutorial was meant for linear screenbuffers, oldschool platforms or softrendering. Feel free to comment bellow for doing the same basic voxeltunnel on shaders or the like.*Some additional info i forgot to mention:

The height of our voxels are determined by the length of the radius. The angle determines the index of columns of the landscape (texture).

The height of our voxels are determined by the length of the radius. The angle determines the index of columns of the landscape (texture).

not 6dof though, is it?

No, the tunnel in Stars/Nooon is not 6dof. It's 2.5D basically like in the Mars demo. The difference is the extra lookup or basically the path from the radius and angle to the linear 2.5D voxel lookup. If I ever understand how to do a fast 6dof in simple terms I will write about it.

dis by mandula had a better implementation from what i vaguely recall

psenough: Thanks for the tip. Just watched it, I really like the FD-voxel tunnel in that one. Or is it free directional? The camera is slightly off at 90 degrees but I can't tell wether it can rotate all the way round. The voxel blobs could simply be just the same buffer with different rotations of the same buffer and moved.

not very helpful, its rather a tutorial for cartesian to polar, as to how to do the actual voxel drawing part is explained in less detail, practically ununderstandable. not a single word on heightmap, perspective, or how to deal with invisible voxels.

so far I was told this kind of effect is simply remapped, that is make a voxel landscape in 2d in the known way, and then simple polar remap it, and voila its a tunnel.

so far I was told this kind of effect is simply remapped, that is make a voxel landscape in 2d in the known way, and then simple polar remap it, and voila its a tunnel.

**Quote:**

not very helpful, its rather a tutorial for cartesian to polar, as to how to do the actual voxel drawing part is explained in less detail, practically ununderstandable. not a single word on heightmap, perspective, or how to deal with invisible voxels.

so far I was told this kind of effect is simply remapped, that is make a voxel landscape in 2d in the known way, and then simple polar remap it, and voila its a tunnel.

At first I got confused too, it read like "go linearly through the framebuffer, and read back angle/radius from tables, then the value from heightmap", so it gave me the impression that it would just plaster as a regular texture the heightmap onto regular tunnel.

But at some point it says "you start with the lowest radius and increase it until it reaches the the end of the screenbuffer, then go to the next angle and repeat".

So, if I understand, you don't move linear in framebuffer, but at radial lines from the center, trying to cover every pixel. Maybe a way is to precalc all x,y cartesian, going from center towards a radial line using very tight angles, noting down in an array pixels not already covered. Then, you do what it was described before, walking through each radial, going from x,y to get angle/radius and use to get heightmap value. Maybe, if you go from edge towards center, you can cover/not render heights that are lower than the previous max height. I just don't know if this coverage would work from angles coming from the sides and if one actually renders pixels or tall radial columns. I need to try this to find out.

yeah I guess I get it what it wants to say, that drawing should be done in polar order but that's only affordable from 486 and faster systems imho, while it can be done much simpler as I described.

lowest radius would mean start with the smallest "circle" but oldschool voxelscapes start with the nearest voxels to the camera. so the guy would have also huge amount of overdraw.

shouldnt write a tutorial when he is not knowing the basics.

lowest radius would mean start with the smallest "circle" but oldschool voxelscapes start with the nearest voxels to the camera. so the guy would have also huge amount of overdraw.

shouldnt write a tutorial when he is not knowing the basics.

f**k you Oswald. In your face: pluto128. . Read there might be other methods. I should have written: there are other methods if it makes you happier. Please, write a tut instead of complaining. or look in mirror. prejudging peoples knowledge about things when you do not know it, is lowlight. i know your type, you're just searching for flaws in what other people write instead of looking at what you write yourself.

**Quote:**

We should computing these points and store them in a lookup-table for fast access (there might be other methods).

Somewhat hit a nerve.

you are right, I could have adressed the critics more nicely, but in frankly your tutorial goes like this:

Oswald: quick and dirty tut is quick and dirty.

I was about to give the same criticism as Oswald. This "tutorial" tells you how to make the classic movetable tunnel that we all know by heart and does a really poor job at explaining the meaty bit. There's a lot better discussion about the voxel tunnel here btw.

FWIW, back in 1999 or so I e-mailed Rod/Mandula and asked about his freedir voxel tunnel. I don't recall exactly what he said but IIRC he said that it's rendering 16 freedir tunnels at once. Kind of makes sense.

FWIW, back in 1999 or so I e-mailed Rod/Mandula and asked about his freedir voxel tunnel. I don't recall exactly what he said but IIRC he said that it's rendering 16 freedir tunnels at once. Kind of makes sense.

next up... a voxel lump!