I had the idea that I could set one material to be "water", then I will just use a special shader to give it shader effects.

Then I figured a problem that there won't be "borders" between the water material and another material, as the extractor will still extract it as one mesh.

The solution of course is to keep editing in one volume but when extracting copy the volume once with all but water data and extract and then extract another mesh from a volume where only the water's material was copied to.

This is simple enough but I was wondering if perhaps it will be possible one day to have this option inside polyvox itself and perhaps some other possible features to support water/fluids in polyvox.

Nothing critical or urgent, as I said the solution is really simple but just opening the door for more ideas on what could be done for things like fluids. Maybe gases/clouds features could be added too? Just ideas and nothing specific either, I am not even sure what I am saying as I didn't have anything specific in mind yet

This could be done with a custom surface extractor + custom voxel type.

I have no clues about marching cubes, but I do have an idea of how to do this with cubic surface. I was thinking about trying this myself, but I won't have time for a while. I should at least fix my own codes problems first...

Edit: I currently use multiple volumes, eg 1 layer for solid opaque, 1 layer for solid transparent, and 1 layer for non-solid. This works, but u end up with duplicate faces many of which will never be visible.

It's funny, only last weekend I was saying to Matt that at some point people would ask for transparent voxels. I guess that time has come

I do think that it makes sense for PolyVox to support transparent voxels. I wasn't really thinking of water (because the associated physics are outside of PolyVox's scope) but things like ice and glass. Water is ok to if you can handle updating the physics yourself.

I think it probably means moving some logic from the surface extractors into the voxels. At the moment the surface extractors call the getDensity() function on a pair of voxels, and if the results are different sides of a threshold then triangles are generated.

I can imagine we would want some kind of VoxelType::hasSurface(Material1, Material2) function, which uses the materials to determine whether a surface exists between them. Or maybe just a VoxelType::isMaterialTransparent(materialID) would be enough. Also, the transparent mesh will need to be seperate from the solid one so it can be rendered/blended differently.

Things are going a bit slow at the moment, because I'm busy at work and also working on a project which uses PolyVox rather than on the library itself. But this support for transparency is on the todo list and I think it will happen. In the mean time DefiniteIntegral's multivolume approach is probably the way forward.

It would be useful to differentiage beween "solid" and "non-solid" voxels as well. Even for non-transparent materials, if the camera is intended to pass through the material then a surface may need to exist between that and another voxel type.

Consider the following example cases:
Transparent solid glass -> Transparent non-solid liquid : Needs faces in both directions
Transparent solid glass -> Opaque non-solid liquid : Needs faces in both directions
Opaque solid stone -> Opaque non-solid liquid : Needs face in 1 direction only
Transparent non-solid liquid #1 -> Transparent non-solid liquid #2 : No faces in either direction

So for this to work voxels would need to be marked as transparent/opaque, and solid/non-solid.

My plan for liquid is to extract the water surface since I'm using a custom extractor, it's not to hard to add a buffer for the water surface. Last week I messed around with rendering transparent blocks. If you want to do it exactly like Minecraft, you can either: 1) render the water block front to back with depth rejection and alpha transparency, 2) render water blocks with two passes disabling color writes first pass and z reject in 2nd pass, you can do this in an order independent manner, 3) handle transparency as a post process.

I would prefer this to the other proposed methods for then it's not limited to "solid -> opaque -> air" but could create many other combinations, too.

One thing I was thinking about...

It seems like storing render/pass, solid/non-solid, transparent/opaque settings per-voxel would use up heaps of extra memory. And since each material is likely to always have the same settings, it might make sense to just have a material register where material settings are defined. Then the extractor can refer to this when comparing neighbor materials for determining how many faces need to be generated.

As to not restrict to specific categories like "solid", "water" etc, the material register could simply map a material to a layer number. Then layer interactions could be defined - eg Layer 0->1 renders a face, and Layer 1->0 does not. The extractor can call a function in register to inquire what faces to be generated from material A to B, and register can return something like NONE, FRONT ONLY, BACK ONLY, or FRONT AND BACK

Not sure how well this would work but I was considering trying something like that.

and also...


Yep, your both talking about the same kind of system here which is also what I was describing. It seems flexible, however I think it is also going to move quite some logic into the Voxel class rather than the surface extractor. Maybe this makes it more complex to write new Voxel classes. Or maybe it's not so bad, I'm just thinking aloud really.

The other aspect is that there's more to PolyVox than the surface extractors - for example how should the raycasting respond to transparent voxels? Or the ambient occlusion generator? Simply flagging voxels as solid or transparent might be more useful here.

And maybe it's possible to get the best of both... it just requires some thought



PolyVox wouldn't dictate what data should be stored per voxel - just what data a voxel should be able to provide. For example, a voxel already has both getMaterial() and getDensity() methods, but if only a material is being stored (e.g. Material8) then the density is simply computed based on the material (material 0 has a low density, any other material has a high density). So I agree with you, and the 'material register'would be an implementation detail of the voxel type.

As for the raycasting I can say that for the MLE editor it can be useful to have a choice if to hit "everything", hit only "solids" or hit only "water" or any other specific special type.

For MLE at the moment it is simple, as I said the relevant data is simply copied from the "everything" volume to a "water only" and "land/solid only" volumes. Then again, this all started from me saying I'd like a more standard implementation for it in PolyVox so this is what I have to say:

The RayCast class should be able to hit everything, it should also be able to hit "solids/regular-stuff only" and should also be able to hit "special whatever only".

I don't like the definition of just "solid" and "not solid", as it was brought up the idea of glass, glass is solid. Other options exist too. (for some water might be solid)

When I said "solid" I really only meant the camera was not meant to pass through the surface, while "non-solid" was a surface the camera would pass through.

For all cases that I would use it for, only render/no-render, solid/pass-through, and transparent/opaque for a total of 8 combination's would be necessary. This should cover all the materials I intend to use, like rock, glass, water, lava, ice, air, vacuum, etc.

Possibly more types might be required for other uses.