Hi,

I'm looking into the feasibility of making a voxel tool, and just have some general questions on the technology. The tool operates on voxelized meshes.

1. Approximately how much would disk space would a typical RLE 2048x2048x2048 voxel file use (e.g. storing the voxelization high detail character)?

2. How long would it take to load this RLE voxelization, marching cube it recursively to different LOD's and send them to the GPU? How long would it take to load a detailed game-scene (trees/rock/terrain/characters) by this approach?

3. I'm not really sure how texture storage works with voxel methods.. could you explain this/point me to the right class/bit of reading? does each voxel store a material enum.. or point to a normal, how does this get shared when converted to triangles?

4. Would it be possible to store additional data (e.g two bytes and one float) on some of the voxels, which can get parsed to the GPU vertice storage, as generated from the marching cubes?

Thanks,
Chris

I'm not really an expert on voxels but I will input my 2cent:

1. RLE depends on how noisy your data is.

1 and 2. that's a hard question for me. It depends? Well, RLE is compression is very fast, that's for sure. However, the compression rate is very much dependent on how noisy it is and there is definitely a limit on how much you can compress with RLE. RLE is a pretty simple algorithm that works with well with "bitmap" type of data.

3. Not sure if you are asking how to texture voxels. Look up triplanar texturing (http://www.google.com/search?hl=en&sour ... planar+tex)

4. PolyVox Volume is templatizied on voxel data type, it's a volume of homogeneous data-type.

Ok, these are rather vague estimates... hopefully accurate to within an order or magnitude



1) As beyzend says this can vary hugely depending on your exact data, but in general I have seen that zipping up the data reduces it to a few percent of the raw data size. I think that a compression rate of 100 to 1 is probably the right kind of level to aim for. Assuming 1 byte per voxel, your raw volume would be 2048^3 = 8GB of data. So if you compress it I would estimate 80MB.



I'm not sure how long the loading would take, I've never really measured this in PolyVox. Perhaps you can find some real-life hard drive transfer speeds (sustained, not burst)?



As I recall, PolyVox can run the Marching Cubes algorithm on a 256^3 volume in about one second on my two year old PC. Logically this means 64 seconds for your much larger volume. That's on only one core though, and it's quite easy parallelise so you should expect a linear increase as you increase the number of cores.



Not exactly sure... probably each LOD level will take 1/8th the time of the one above it. So maybe add 15% to the non-lod time. But this could vary depending on exactly where the bottleneck is.



Again I'm not sure... but you should be able to find details on how fast the bus in on modern GPUs. Maybe estimate 30 bytes per vertex and 2 vertices for each partially occupied cell (some vertex sharing will also take place).



In total... maybe one or two minutes? Let's say two.



PolyVox just stores a material ID per voxel. This can be interpreted as a color, a texture, or what ever you wish at rendering time. If your textureing voxel terrain then triplanar texturing is a good option, as beyzend pointed out.



In principle, yes. The traditional Marching Cubes algorithm just operates over a density field, so really the material ID is an example of the kind of data you describe. It's a integer value in the volume, and gets converted into a float and attached to the vertices which are passed to the GPU.

Thanks so much for these detailed approximations, both of you; they really help give me an idea on where to flesh out the framework. Before reading this, I thought the bottleneck would bias to one of processing/{diskspace/memory} - but instead it seems much more of a fine-balancing act (especially with detail generators on the mesh).

Hi, this is quite off-topic, but perhaps some of the developers here have done similar in the past, and can help me. I'm just doing final optimizations for a paper, the C++ implementation isn't using PolyVox.

Each voxel stores 4 bytes of data. I want to crudely pack a float32 Vec "normal" into the first two bytes of a voxel. And the inverse function; from the first two bytes, compute a crude normal vector where xyz are float32.

Does anyone have any advice on a "correct" way to do this?
Thank you

There are several ways to do this I think but I've never done it myself (not there yet).

http://mynameismjp.wordpress.com/2009/0 ... ordinates/

http://www.opengl.org/discussion_boards ... ber=221234

Thanks an awful for lot for these links, they look very promising. I'm just heading out, so will look again in a few hours.

Okay, I just checked them out. I'm not sure if they're quite what i'm after. They seem to convert a float3 xyz into a float2 xy. In some of the deeper links, they pack normals from half3 xyz (48-bits) to half2 (32-bits).

What i'm after is something much more crude, packing float3 (96-bits) into just two bytes (16-bits, or one U16). I love the idea of taking advantage of spherical coordinates, so will look into trying this with some packing.

Thanks again, has given me lots of thought for trying stuff. Let me know if anyone can think of a nice solution; will post immediately when/if I get it working elegantly.
Chris

Edit: Got it working, thanks to some additional help