Hello,

currently I am quite sure if I understood the Polyvox concept. I am wondering about the scope and the vision/strategy for / of the PolyVox Library.

e.g.
I am thinking a lot about things like destroy and heal. This is basically what voxels could do much better than just surfaces (See how easily the OPENGL Example cuts a sphere).

To understand or even design something I would need to understand about the some basic strategies for PolyVox.

E.g. Is PolyVox "just" intended as graphics library converting voxelData to meshes (which is already quite a lot)
Or if it is going to be an engine capable of handling real volumes (like stones, trees, pipes, ....). Maybe having a concept which is extensible (inheritance etc.)

To do that it would be required to know and control quite a lot more of a voxel than just a material and a position. It would be needed to create, manipulate, and track data of each voxel like:
- VolumeID: A body, corpus etc. it initially belonged to (so there is a lot of 0 for empty space)
- The VoxelIds of each of the neighbors of each Voxel (to locate and to manipulate like cutting, melting, blowing away....)
- the material id (which is currently already the case if I understood correctly) an integer for the start. The logic WHAT the voxel does if something happens is the responsibility of the application (0 empty space, 1 is copper, 2 is iron, 3 wood....)
- A state (like new, ok, burned, damp, ....) could be any integer for a start, and the state engine of the application using the Voxels takes care to control the voxel state
- current location vector (x,w,z)
- initial location vector
- a time stamp of creation
- a time stamp of last movement

Lets do an example of a currently not designed game:
Someone fires a cannon and the main wall of the castle falls appart and is spread into the environment (no material "vanishes" the voxels are spread around the castle -> physics based on materials (not textures!) )
A powerful witch is summoned to heal the destruction
She gets a part of the wall (a voxel or a voxel cluster) and magcially (of course a sufficient amount of power is needed for that, calculated by distance and material) collects the voxels
and if the state voxel permits she glues/welds/melts them together to the original shape (a state engine takes care about things like: burned wood will never become a trunk again ... only on a very high level of healing , mortar needs water ....))
another example: nobody needs to design a tree trunk with just one possibility to cut it, let the user decide where to cut and PolyVox creates the correct visual appearance.

Do you suggest to add things to enable applications to do this with voxels to PolyVox (not the game logic but the data of the voxels) or shall this be done by the application?
It think it would enable great possibilities for the application developer having this in a consistent library and we could start to show what voxels really can do Not just displaying bones and brains. Lets break them, melt them mend them glue them together

Please kindly let me know about your ideas and strategy for PolyVox. Maybe I can start with a very simple test once I understood the plans.

Kind regards
J.

I will do my best, though there are many things which are still undecided. But the vision is definately getting clearer as I progress

Basically, yes. There is always this trade off between providing all the features which a user wants, and giving the user the flexibility to implement a feature in exactly the way they need. If you implement a lot of features then it's more useful to people who need exactly those features, but at the time time you now have a smaller group of people.

No, but this is where Thermite comes in. Thermite will provide the game engine layer which is built on top of PolyVox and provides these kind of features. In order to help with the trade off mentioed previously, it seemed to make sense to split the project in two. If Thermite is exactly what someone needs then they can use that, or of they want an engine which works differently but still uses voxels then they can ignore Thermite but still use PolyVox. I also hope that Thermite will be useable by non-programmers, whereas to use PolyVox you have to know how to program.

These all make sense. At the moment if you wanted to store a state you would have to use a seperate volume which you would then have to keep in sync with the main volume (obviously you wouldn't ever pass this second volume to the surface extractor). But that's no problem. You might aso have noticed that the BlockVolume is a template class. This means that in theory you will be able to define your own voxel types and build a volume of those. It's won't work yet though, so for the foreseeable future you best off with seperate volumes.

These don't make so much sense, because a voxel never moves. Each point on the grid is fixed, so the voxel at (x,y,z) is always next to the voxel at (x,y,z+1). If you want a voxel to appear to move, then you could set the old position to material '0' and the new position to the voxel material (in the same way a regualr animated 2D image works). But in practice I think it makes more sense to use normal particle systems for this.

Fine, except for the 'spread into the environment' bit. As mentioned, it is more likely that the voxels would simply vanish (as they can't move) and would be replaced by a conventional particle system. Of course, each particle could be a cube-shaped mesh so it looks like a voxel At this point, we are talking about the Thermite level rather than PolyVox.

Getting tricky. It would be hard to really gather the original particles and reassemble the wall. However, if we had kept a copy of what the original castle looked like then it should be possible to grow it back a few voxels at a time. So just a different kind of spell

Yep, sounds fine. It basically does this already

As mentioned above, I think the application could keep a second (or third) volume for the time being. In future versions it might be possible to use the template aspect to build this into PolyVox, but I don't think it's essential.

Yep, there's lots of fun stuff to try! I really think there could be some fun games here, just got to get it done

Thank you for your reply. This helps a lot.

Voxel:
For me the limitation a voxel is fixed to a location is new. I assumed its a bit of a volume lets call it an atom. On the other hand it makes quite sense to understand a voxel as a fixed location in space. The limitations are maybe much less then I currently think they are. In the universe a volume element is also fixed and galaxies are moving trough them.

Particel system:
Well I think this offers new possibilities but i suppose it limits the control over the volume - well I am not in particle systems hence I might be totally wrong. Currently I prefer the sprite-like voxel movements. And once the Voxel space gets bigger (some giga voxels) I suppose there is no difference in the possiblilities, its just a different approach.

Separate Volume:
I fully agree this explains was what I had in mind.

Thank you again for your kind reply, now I need to sit back and let my brain storm to create a project - which is fun and shows the possibilies of Voxel based technology.

Kind regards
J.