Adding support for different volume representations

David Williams · **Joined:** Sun May 04, 2008 6:35 pm **Posts:** 1827

realazthat wrote:

A Volume class that instead of storing the entire volume, simply implements getVoxel(). This makes it more amenable to procedurally generated volumes. Caching/compressing etc. is all up to the implementer.

I think that with the work to seperate volume representation from the algorithms (here), we may already be able to do what your describing. Or if not then we're certainly pretty close. At any rate I do agree it a useful and interesting feature

realazthat wrote:

A smarter Marcher for some use cases, would be given a starting voxel position, and only march along surfaces. Thus, instead of iterating through n^3 voxels, it would travel across O(n^2) in a normal use case. Of course it is possible to make a surface that has a worst case of O(n^3) but that would obviously not be a good use case for a "Crawling"/"Creeping" Marcher.

Yes, I think it's an interesting approach. But I think the difficult part is choosing a starting point, especially if you have several disconnected surfaces. One of the links mentions it's a good option for metaballs (when the starting points are easy to find) but I think in the general case it is more difficult.

realazthat wrote:

Together these two ideas can allow for faster and *much* less memory hungry mesh generation from voxels.

Maybe. I think this could go either way depending on the data and the size of the region being extracted.

realazthat wrote:

Oh and btw, I really love your coding style; it matches my own +/- some tricks.

Thanks

realazthat wrote:

But fractal noise naturally builds down from the top ... that is, you get a low resolution of noise (smoothed out), and you then add its own (faded) image four times into itself at half resolution; this adds detail, but from a distance this detail is not really visible. I am trying to apply the same idea to voxel generation. I dunno if it will mess up the crack-patching algorithm; I'll get back to you...

Maybe... I'm not sure how well this will work. You're in uncharted territory here :-)

realazthat wrote:

To support destructibility in my world, I intend to use an inverse Volume; one that would indicate where the world differs from the noise generator. Thus, my volume's getPixel would first check the inverse Volume, then if it finds nothing, it would ask the noise generator for a voxel (I am using the Simplex noise generator for 3D btw).

Yes, this sounds sensible. Your inverse volume would be mostly empty and so would compress down very well.

David Williams · **Joined:** Sun May 04, 2008 6:35 pm **Posts:** 1827

Actually I've seen that library before but it's very interesting. There is a programmers guide here with a lot of useful technical information. I have skimmed over it in the past, but I should probably print it out and read it on the train one day. Although it's designed for a different purpose I'm sure there will be a lot of useful ideas which could be considered for PolyVox.

David Williams · **Joined:** Sun May 04, 2008 6:35 pm **Posts:** 1827

This weekend I got a chance to look at that Field3D library in more detail. I haven't actually looked at the code, but I did read the whole programming guide to get a feel for it.

I must say, it's a pretty cool library, and actually it has a lot in common with PolyVox. The main advantages of Field3D are:

Nice class hierarchy. Volumes are templatised on voxel type (as in PolyVox) but they also have a set of base classes for defining the interface. Of course, this is similar to what we've already been discussing in this thread.
Serialisation via the HDF5 format. PolyVox does have some serialisation but it's quite primative by comparison.
As well as Dense and Sparse volumes (similar to our Simple and Large volumes) they have a 'MAC' volume which is apparently useful for fluid simulation.
A nice mechanism for allowing volumes of different resolution to occupy the same space (we may want something like this for smooth LOD).
Their library is generally a bit more polished and complete.

On the other hand, there are some things in PolyVox's favour:

Numerous algorithms which operate on the data such as the surface extractors, raycasting, A* pathfinder, etc. Field3D is only concerned with storing the data.
Infinite/paging volumes. Field3D mention this as future work.

But overall the main thing I noticed were the simularitites, as we've made quite similar design decisions. Hopefully that's a sign that we're doing something right.

Adding support for different volume representations

Who is online