Hmm I hadn't thought about raycasting apart from ray queries and lighting.

Do you think CPU raycasting would be faster than extracting/compiling vertices, then rendering on GPU? I am guessing if I use CPU I would need to deal with all the texture sampling / anti aliasing etc myself... ?

How about CUDA? I haven't used it but people seem to do neat things with it. Maybe it is possible to walk the octree and send single quads to a CUDA app to do render operations in parallell or something.

I haven't tried cuda yet, but after a cpu implementation that would def be the next step.
so far I have a pure glsl raycaster for 3d textures containing a minecraft world and a really crappy cpu raycaster that i only wrote for testing sth.
but I'm sure it would be faster in a octree, especially in a fully linked one.

You can try OpenCL. When I looked at it it was not as mature as Cuda but was still plenty fast on both CPU and GPU. I messed around with a crowd thing and implemented a few of the recommended optimization and it was blazing fast on the CPU (like taking 1ms for 10,000 entities potential field pathfinding but that means absolutely zero to you). And it should work on both CPU and GPU.

Also I remember reading about ray tracing on the GPU where you can traverse octree by using a stack. Dont' remember all the detail. On the newer GPUs with local memory you should be able to do octree traversal without problem.

Wow, that's really cool. Actually it reminds me of Cube/Sauerbraten in that the world is built up from different size cubes. Having the size variety really allows a nice approach to modelling.

But I wonder whether you have a minimum size for your cubes? If you do have a minumum size then PolyVox can (in principle) match your behaviour but setting its voxel size to be your minumum size. But if you don't a minumum size (i.e. you have a more dynamic approach to building the octree) then you can essentially keep on adding detail as far as memory would allow. This would be a cool system

I don't think I'd try raycasting the structure because it would make texturing, etc much more difficult. It would be ok if you just had a single colour for each voxel and made up for that by making the voxels very small (i.e. the detail is in the geometry not the textures) but at this point you are talking about SVO type rendering.

Anyway, it's cool stuff so keep us up to date

Yeah I do have a minimum size. I found I have to limit the size otherwise floating point errors occur. So the smallest voxel is 1.0 in size and the whole tree is 2^23 in size. Any smaller scale and voxels start collapsing triangles etc.

At the moment it uses a lot more memory than it really needs to due to some duplication occuring because I keep the tree and mesh completely separate (so they can be operated on in different threads). I may try merging the tree/mesh operations into a single object/thread and see how that goes.

It would be interesting later on to try loading the exact same scene in octree/polyvox and see how they compare for extraction times / memory use etc. Then we could get a better idea of the strengths and weaknesses of each approach.

Another idea I had was replacing branch nodes in the tree below a certain depth with polyvox style RLE compressed arrays, to get the best of both. Seems complicated though, so that's something to explore in the future.

Ok, so you have a minimum size but you still cover a huge range of possible scales. I imagine that it is quite easy for you to place a tiny cube next to a huge cube, whereas in PolyVox this would require a lot of voxels to be processed and/or loaded into memory.



I suspect that the main advantage of your approach would be the memory usage, but on the other hand it might be harder to implement paging (then again you might not need it). As for the extraction times, the PolyVox extractor has no knowledge of how the volumes are stored. If you know you have an octree then you can pobably write a dedicated extractor for this case, which might have some benefits. But it depends whether you want this coupling between extraction and storage.

Ah ok yeah. I have two extractors, an octree specific one and a linear extractor that is independant of the tree format. Performance varies depending on how many voxels need re-extracting.

I have already added preliminary support for paging, by diving the octree into sections addressed with 4D coordinates, where 1 section is 8,256,256,256 in size. (So total of 1 + (2^8)^3 + (2^16)^3 sections.)

It should be pretty trivial at this point to page individual sections in/out of memory. Which would be important for sections in the smaller scale range to allow larger scenes.

Since CUDA runs on CPUs these days and not just NVIDIA cards, and it has inbuild texture filtering support + texture arrays, I am considering switching to a GPU based raycasting or rasterizing approach and doing away with mesh extraction entirely. Need to do a bit of research and testing first though before deciding.