being so fascinated by voxlap I wrote a similar engine using OpenGL. I had the idea for a long time to combine the raycasting algorithm with OpenGL. (see some older threads here on voxlap)
So here's the result:
ATTENTION: in order to run the demo, you _must_ copy a voxel data file from ken (any vxl file with 1024x1024 grid size, like the one from the cave demo or the game data shipped with the voxlap library) to the main directory and name it "cave". Then run any batch file.
This demo is not intended to be public, just for all the voxlap fans here. I'd love to get feedback, especially from ken :-)
Sebastian
Awesoken at
Let's play "guess that algorithm"! Ok, your demo is quite impressive. I can see you got the raycasting working. What I find most interesting is the orientation of your 4 quadrants. They are aligned to the world. Is that because your raycasting algorithm uses conditional statements to step along (x,y) coordinates efficiently? In Voxlap, I can handle all 4 cases in 1 loop. My code looks something like this:
long ip, d, tp[2], ti[2], ipi[2];
...
{
k = (((unsigned long)(tp[1]-tp[0]))>>31);
d = tp[k]; tp[k] += ti[k]; ip += ipi[k];
//ip is the (x,y) grid offset, d is the x-y dot product distance
}
If you want to see a working example of the above algorithm, take a look at "BLOCKSCAN.KC" which is included with EVALDRAW.
Also, I'm not sure where you're using OpenGL in your demo. It looks like you're using only for the second pass, where you copy & project the color data to the screen. This part can be done pretty fast in software, so that's really not accelerating anything.
If my guesses are wrong, then you should either explain your algorithm, or perhaps send me the source code : P
Sebastian at
Your guess on my algorithm is very good: I use OpenGL only for the second pass
and I know that the speedup is minimal or even negative on machines with older Graphic Hardware. It's sad,
because I had all these ideas in theory and they didn't work out as I wanted.
my algorithm works as follows:
As I step through all the columns hit by a raycast plane I determine (in software) which parts are visible.
I project everything in this plane on a virtual projection line which has a constant distance to the eye point and is perpendicular to the ground.
Then I use OpenGL to project a rectangle on the screen using a stencil buffer, thereby filling the whole screen.
So I dont render lines on the screen and combine them as you do in voxlap.
There are no distinctions between quadrants in my code.
I step along the grid very efficently using only incremental operations like
in your code. However I must admit that I have one branch in the grid traversal,
that's reason enough to have a closer look at your blockscan code :-)
Also I calculate the grid boundaries (which are required for the "perfect" looking cubes) using interpolation which requires one mul too.
I know that the main bottleneck is not the grid traversal, instead it's the memory access. How are you origanizing the world in voxlap?
I have for every column just a simple array where I store the number of visible parts, their length and the actual voxel data.
This has the drawback that the column processing code is slightly slower compared to a version where I simply would store the solid/air information in an array.
However this version would require 32MB just for this without any actual voxel data in a map sized 1024x1024x256.
and ken: you once said that you cast about 300 planes when looking towards the horizon and "a little bit more" when viewing from above.
In my demo I dont have any culling currently active so I render always a constant number of planes and in order to get an output compared to voxlap
I must render about 800 planes when viewing from above. Is this "a little bit more" or are you using any trick for this case?
Sebastian
Awesoken at
I know that the speedup is minimal or even negative on machines with older Graphic Hardware.
I suspect it may be deceleration on newer graphic hardware as well. It wouldn't hurt to try both methods and compare.
I calculate the grid boundaries (which are required for the "perfect" looking cubes) using interpolation which requires one mul too.
You shouldn't need to do a multiply for every column just to calculate the distance to grid intersections. See BLOCKSCAN.KC.
How are you origanizing the world in voxlap?
The layout I use in memory is the same as the VXL format. In memory, I also need to maintain a 1024x1024 array of pointers to the start of each column.
I must render about 800 planes when viewing from above. Is this "a little bit more" or are you using any trick for this case?
Does writing the whole inner loop in assembler language qualify as a trick? :) Voxlap uses a lot more planes when you look straight up/down ... something like 1000 I believe. Viewspace culling is very important. For a 90 degree field of view, it will give you a 4x speed boost when looking towards the horizon.
Frobozz at
Any possible way you could put a Linux version up here? I just recently switched to Slackware so I'm stuck not being able to run any of these demonstrations. :cry:
If you need it compiled, I can compile it. :wink:
Sebastian at
It wouldn't be much effort to do that, but I dont have a linux machine here. When I've finished my Voxelengine there will be a port too for sure.
For now get a windows machine and try it.
Frobozz said
If you need it compiled, I can compile it. :wink:
:D :D
Sebastian
Sebastian at
Heyjo
Since I lost interest in developing the demo I publish here the source code. Maybe someone else takes this as a starting point and makes something great out of it. (hopefully :-)
Compared to VoxLap it's too slow and I must say I'm not going to write the whole thing in assembly just to compete with voxlap. But I would be very interested to see if someone can speed up the code. (ken?)
The source code is completetly open and you can use it wherever you want, but it would be nice to hear from someone if he/she uses it. Also,
a port to Linux would be great.
The source code is completetly open and you can use it wherever you want
Completely open in which way? I suggest you find a suitable license for your code. My first suggestion, of course, is the GPL, but there are plenty of other open source licenses to choose from. You could also take the roll-your-own-license approach Ken took with the Build source and write your own license. Either way, I would find a license unless you fully intend for your source to be public domain, meaning anyone can take it and do whatever they like with it, including selling it and using it in commercial products.
Awesoken at
I don't have VC71, so I made this little makefile to compile it at the command prompt using VC6:
Now, when I run the BAT file, all I get is a black screen. Did you by any chance forget to include your house data? Where can I get a copy of that?
Sebastian at
I didnt include the house file because the file size would be too big. Just take any of your vxl files (cave demo files for example, I'm sure you have plenty of them :-) ), rename them and it should work.
If you see a black screen at the beginning, just move around a little bit with the mouse.
Sebastian
Sebastian at
ken, just curious: did you ever have a look at my code and saw something which you would optimize?
And noticed that you didn't even give credit to ken for the "house" voxelmap... not nice...
Anonymous at
read the readme file first before complaining!
Anonymous at
That's the readme of the archive linked there...
VOXEL RENDERING DEMO
SEBASTIAN SCHOLZ
COPYRIGHT 2004/2005
--------------------
1. INTRODUCTION
This Demo shows how to render a 3d array of data (Voxel Space) exploiting vertical ray coherence. The idea is to cut the whole space with lots of planes in order to generate the output. You need at least a Pentium Pro and a graphic adapter supporting OpenGL to run the demo.
To start the demo, run one of the batch files I've included.
2. CONTROLS
Movement: Mouse,w,s,a,d,q,e,r,f
Speed Up Movement: Hold SHIFT
Toggle Rendering Mode: F10
Increase/Decrease Quality: F12/11
Exit: Escape