I've had this concept for awhile and haven't ever really put it down to paper mainly because I haven't really figured out how it might work. I'm hoping I can get some brainstorming going on here about how to approach the following.

One major problem I have with voxel-based worlds is that the common way to do it is to represent the entire world under one voxel array. Lets pretend we have a small universe of asteroids in this voxel world. To 'move' an asteroid one has to modify the voxels a step the direction of the movement.
This is an expensive thing to do.

So I thought, why not represent each object - Asteroid, planet, rock - as its own self-contained voxel array and then place that array in 3D space. That way its trivial to move the resulting voxel mesh around and not have to perform large amounts of voxel changes. If two asteroids collide you could merge the two voxel arrays (expand A to encompass B, copy over B data, delete B).

Sounds simple at a high-level, but I can't seem to really wrap my head around an actual implementation.

Would love to get feedback and ideas on this.

Basically this should be straight forward with the exception of the part I quote below. Check out http://www.master-space.com/ for an example of a project which uses PolyVox and appears to do something like you describe.

You basically want to have a node in your scene graph for each region/mesh of the PolyVox volume, and all of these would share a common parent node. The parent node represents the whole volume, and making changes to the volume means you need to update the child meshes as usual. Transforming that parent will then cause all the children to move with it.

Even with just a single volume this is a sensible approach because it means you can move your voxel terrain around in the scene. With multiple volumes you just want several of these parent nodes (each with their own volume data) and they should all be children of the root node in the scene. There's nothing very PolyVox-specific about all this.



Now this is the tricky part I guess it's possible in theory but might run a bit slow. Would you really want asteroids to merge like that anyway?

Well, I'm not sure. I think it'd be very cool - You'd have it destroy a number of blocks in the process based on the impact speed. I think it could turn out very well...IF we could over-come the speed at which the copy happens.
I wonder if its possible to write a 'merge' function that actually stitches two regions together without copying. What do you think?

Persumably it would need to be spread over a number of frames as you'd want to see the merge occuring? I think this would also make it tricky... after you done the merge once it's not clear how you further update the volume



Probably it would need to be at a higher level than PolyVox, because it would need to take into account the transformations which are applied to the volumes.

Also, do you know about metaballs? There is some simularity with what you are talking about and the merging is more natural. Perhaps these concepts could be adjusted. Maybe a surface extractor could consider multiple volumes as part of the extraction process to achive this effect. All very complex though!

Good points - Maybe the destruction process could happen before merging:
1. The asteroid meshes collide - Engine works out where and you deduce the voxels responsible for that part of the mesh.
2. Destroy those interacting voxels on both asteroids.
3. Reduce the velocity of both asteroids - Some simple physics interaction here.
4. Repeat 1-3 until the velosity of both objects are < x.
5. Perform the merge and/or copy into a single volume and single asteroid mesh.

I think the only limitation here is step 5 - Getting it done in a single frame.

Hey there!

How accurate shall the merging be? Maybe you could hideaway the real process with a neat collision animation/particle effect or something like that and simply create a new asteriod where the two before collided.
You could assign the different asteroids something like a weight class and generate a new asteroid based on that.
Of course the area you have to fog could become quite large and thus ugly...


If you really want to see them merging maybe a specialized data structure could speed things up. Maybe some variant of an octree so you can skip empty leafs while copying?

Depending on the required effect, you might get away with not actually modifying the voxels until the asteroids have stopped moving. They can hit eachother and start to intersect, but the player cannot see that part of the astroid is inside the other asteroid because the player is outside of both. Especially if you cover it up with smoke and particle systems. Then yiou could merge the volumes once they have stopped moving. I'm still not sure how convincing the whole thing would look, though.