Fully Destructible Levels - New website and domain!

[thloh85]

This friggin rocks...
BTW, is this some sort of CSG stuff? Mind to describe a little how you make this?

[PolyVox]

Thanks

The world basically consists of a 3D grid of values. A value of '0' represents empty space, while any other number identifies the material which exists at that location. With this simple representation it is very easyto modify the world - you just set values in this grid to '0' to destroy material. The 3D grid of values is then converted to a mesh for rendering, using an algorithm called 'Marching Cubes'.

All demos so far feature a 3D grid (volume) which is of size 256x256x256. But on my current version I'm pushing 1024x1024x1024 which should make the worlds bigger and nicer...

You can read more about how it works here: http://www.thermite3d.org/joomla/index. ... 7&Itemid=8

[iio]

Congratualtions! This is awesome. I've always thought that voxels were just generally neat and wondered why they hadn't taken off. Anyway, not trying to be picky but the screenshots look very powdery which is what I'd expect from such a system. Is there a way to smooth the image so they look more realistic? And does anyone know of any links to such example? I ask because I'm about to graduate uni with a Bachelor in Comp. Systems Engineering and need to build a portfolio up. I'm very interested in AI and need a game world in which to run agents and I thought that voxels can do some pretty neat things in the way of interactive environments.

Also, do you have a dev environment yet for creating structures and things? Something like a construction set where you can drag'n'drop materials, shapes etc and link them together? I see you have integrated Qt(yay!). Qt is great and would be ideal for a construction set.

[PolyVox]

I'm glad you like it I'm still working on it nearly every day but it's amazing how long it takes to write a game engine!

For the smoothing, I do have some prototype code to handle this. Most smoothing algorithms require some kind of adjacency information but I don't want to spend the processing required time to build such structures (as the environment is dynamic). My approach is instead based on 'P-N Trianges', except I move the existing vertices rather than inserting new ones. The result (with and without smoothing) looks something like below:




High quality normals also play a role in this.

As for using it for an AI world, this could be interesting. Someone already tried a project along these lines - see the project 'Colony' on the featured projects page:

Thermite Featured Projects

For generating environments, the only tool currently available is a heightmap-to-volume converter which I use and maintain. There is also an old mesh-to-volume converter (used for the castle and Ogre head volumes) but I have to do some work to bring this up to date. If you want something more complex than a heightmap, your best bet would probably be to generate it procedurally.

[nikki]

Cool stuff man, there must be quite a bit of math behind it. I like how there's just a grid of space, and a 'material' at each 'point'.

[PolyVox]

Nah, there's not too much maths. The whole system is conceptually quite simple - the tricky bit has been to optimise the surface extractor to run in real time. And of course it's hard to keep the memory usage down, bit I have some more work to do here...

[iio]

Thanks for the info. I have another question? How is the info about the world stored? I'm assuming its some kind of matrix data structure with integers(?) representing the various material types? Have you thought about the DMM possibilities of your engine. I thought it would be awesome to take everything that's static in a game, apply a voxel converter and give each material type its own properties so you get bending, twisting etc.

Also, have you any functions to reduce the size of the terrain matrix via regression or something similar? It would be awesome if you could take a terrain and use regression or something to compress the data matrix into something very small. But re-calculating it every time the landscape is deformed would probably be a hassle. Although you might take a page from some image compression algorithms and extend them to three dimensions. I imagine at least some of the properties would be the same.

[PolyVox]

Thanks for the info. I have another question? How is the info about the world stored? I'm assuming its some kind of matrix data structure with integers(?) representing the various material types?

Yep, that's it exactly. Each voxel is nothing but an 8-bit integer which denotes the type of material at that location. Actually the Volume class is templatised so in theory you could have other types (16-bit, even vectors?) but I haven't actually tried that.

Have you thought about the DMM possibilities of your engine. I thought it would be awesome to take everything that's static in a game, apply a voxel converter and give each material type its own properties so you get bending, twisting etc.

Actually there is a difference here between my work and DMM. In my engine voxels never move. They can be turned on and off, or you can change the material. You can turn one off and turn it's neighbour on so that it appears to move. But you won't be able to get bending, twisting, etc.

There's actually very little physics invloved (I'm no physics expert). When an explosion occurs it simply turns off all the voxels within a certain radius, causing that geometry to disappear. There is Bullet physics integration, but that is just to allow objects to bounce around the environment with rigid body physics.

Also, have you any functions to reduce the size of the terrain matrix via regression or something similar? It would be awesome if you could take a terrain and use regression or something to compress the data matrix into something very small. But re-calculating it every time the landscape is deformed would probably be a hassle. Although you might take a page from some image compression algorithms and extend them to three dimensions. I imagine at least some of the properties would be the same.

Yes, compression is already implemented. On disk run-length encoding is used which get a pretty good compression ratio (maybe 50:1?). But in memory I need to be able to modify the data in real-time which limits the kind of compression algoithms I can use. Basically I break the world up into cubic blocks, about 32x32x32. Many of these blocks will be homogenous, and in that case they are shared with other blocks with the same value. I haven't really tested what kind of ratio this give though, it's probably quite scene-dependant.

[PolyVox]

********** Update - New Release **********

Hi guys, I've just released the July 2009 version of my engine. The main changes include:

• Support for larger and non-cubic volumes. The previous demo only featured volumes of 256x256x256 voxels, where as the new version contains some maps which are 1024x1024x256.
• An optimised version of the Marching Cubes algorithm in PolyVox, which now runs 2-3 times faster than before.
• A multithreaded surface extractor which improves load times and interaction.
• The start of a new material system, so that every voxel no longer has to use triplanar texturing. This will be built upon in future releases.
• Some new artwork, courtesy of Jaz Wilson.

The new demo is available for download here: http://www.thermite3d.org/releases/Ther ... ly2009.zip
If it won't run, you might need the Microsoft Visual C++ 2005 SP1 Redistributable Package (x86)
Source code (under the GPL) is available from SVN here: http://sourceforge.net/svn/?group_id=44243

There are some performance issues to be resolved, so start by loading a small or mediam map. Move the camera around with W,A,S,D, and the mouse. The tank's turret can be controlled and fired through the panel provided but the tank can't be moved at the moment.

More information about the project is available on the project home page at http://www.thermite3d.org/

New screenshots:

[xadhoom]

Looks great!

Downloading!

Did you investigate a GPGPU implementation of marching cubes?
The voxel approach seem to be a hot topic with the current raytracing development in certain companies...

[boyamer]

Is this free for commercial use?

[PolyVox]

Looks great!
Downloading!

Thanks, do let me know if it works as I haven't really tested on any systems except my own. It would be good to know it's not missing any .dlls, etc.

Did you investigate a GPGPU implementation of marching cubes?
The voxel approach seem to be a hot topic with the current raytracing development in certain companies...

I'm keeping an eye on the latest research but not intending to switch to it yet. GPU Gems Chapter 3 is interesting, but it's really just a proof of concept and lacks the destructible element. I think it would need a lot of GPU memory too, plus the volume would still have to exist in CPU memory for physics, etc. And lastly, with technologies like Larrabee around the corner things might start moving back to the CPU anyway. But I'm keeping an eye on it, it will be interesting to see how things play out.

Is this free for commercial use?

It's under the GPL, which isn't very commercially friendly. But this is deliberate, so that I can maintain the option of offereing a commercial license at some point if there is any interest.

[xadhoom]

Hi PolyVox!

The latest version works perfect!
(I just got a virtual memory error when loading a "large" map and having firefox/thunderbird open and Ogitor compiling )

I miss some tiny particle effects on explosion just for the feel of it.

xad

[PolyVox]

(I just got a virtual memory error when loading a "large" map and having firefox/thunderbird open and Ogitor compiling )

Yeah... guess I have some more improvements to make there. I'm pretty sure it leaks memory like a sieve

I miss some tiny particle effects on explosion just for the feel of it.

Agreed, along with some sound effects. These things aren't really difficult - I've just been focusing on the 'core' technology so far...

[xadhoom]

Actually I´m not able to load one of the large maps successfully. Is there some kind of memory requirement?

BTW: Different textures should be blended where they meet each other. This would look much smoother...

[iio]

Wow this is great! Congrats on the improvements. As mentioned before though, will you be blending the textures where two material types meet? Not a biggie but just wondering. Also, is it possible to use this with existing polygonal engines? I have some ideas I'd like to use it for am thinking I could save myself some processor time by using plain polys in certain areas.

[PolyVox]

Actually I´m not able to load one of the large maps successfully. Is there some kind of memory requirement?

On my machine the 'Thermite Logo' terrain uses up about 800Mb. This is clearly to much, but actually only about 200-300 of that is the volume itself. The rest is intermediate structures which should be deleted once the mesh is transferred to the graphics card. Also the memory usage increases s you destroy theterain because it's not removing the old mesh from memory. Guess have some tidying up to do here

BTW: Different textures should be blended where they meet each other. This would look much smoother...

As mentioned before though, will you be blending the textures where two material types meet?

Actually, if you look at the castle map you can see this is alrady done. Textures blend over one voxel. The castle map is different to the others in that all voxels are textured in the same way - i.e. by projecting the texture along all three main axis. The terrain maps are more complex because the surface textures are only projected down from above, while the underground ones are still projected along all axis. Hence the mesh for the terrain is split into more pieces, but I still hope to get blending working for them at some point.

Also, is it possible to use this with existing polygonal engines? I have some ideas I'd like to use it for am thinking I could save myself some processor time by using plain polys in certain areas.

I think it should work fine. The tank of course is polygons, as are the shells it fires. Ogre doesn't even know about the voxels - as far as it is concerned it's all polygons anyway.

[milliams]

The higher resolution volumes really add something - it looks a lot smoother now.

[PolyVox]

***** Update - New Screenshot *****
Hello again,

Following on form my previous update in July, I have spent the last month or two working with an artist to build a simple game around the Thermite3D game engine and the concept of fully destructible environments. The game will be called 'Apophis 2036', and involves defending the earth from the incoming Apophis asteroid. There is no game play yet, but we do have a destructible model of the Earth (see screens below).

One of the drawbacks of the voxel-based Thermite3D engine is it does not support traditional UV texture mapping (because geometry is generated on-the-fly, there is no chance for the artists to assign UV coordinates). This work on a destructible Earth has given a good opportunity to demonstrate how texturing can be performed without explicit UV coordinates:

• The surface of the Earth is based upon NASA's Blue Marble data set, converted into a cube map. The normals of the Earth are then used to look up the appropriate colour.
• The rock just under the surface is done with triplaner texturing (as has been seen in previous screenshots).
• Perhaps most interestingly, the lava in the core is generated using real-time 4D Perlin noise on the GPU. This means that it is actually animated (I might make a video at some point). To shade each fragment, it's world-space x,y,z position along with the current time are fed into the Perlin noise generator (ported from GPU Gems 2). Four octaves of Perlin noise are combined and the result looks up into a lava-coloured gradient texture.

Anyway, I haven't prepared a demo this time so you can't try it. The latest demo is still the July 2009 release. But I'll try to release another demo over the next couple of months.

[xadhoom]

Looks good. SO the player will control some kind of space ship with a very large anti-astroid cannon?

[PolyVox]

Looks good. SO the player will control some kind of space ship with a very large anti-astroid cannon?

Yes, something like that. We haven't really worked out the exact gameplay mechanics. Maybe the missiles are fired from the ship, or maybe the ship will have to fly close to the asteroid to 'tag' it and then the missiles could be fired from earth. Or maybe the player just clicks on incoming asteroids to lauch missiles at them. We have to play with a few ideas and see...

[weylin]

I have a question;
How practical is this system for something such as an animated model?

How would it turn out if I were to use this for wounds to organic objects, or damage to a mechanical object?
Would there be too much lag?
What if the mesh change was of low resolution, only a handful of polygons?



Me and some contacts are working on a Multi-Species Survival Simulator, and we believe this would be of much help.

another thing we are working to have is scripted animation. Basically, rather than "fixed" animation, the character moves in accordance to the terrain they are on, actually placing there feet down on the ground and such. (Seen this done before, but it was for a mechanical walker)

This particular destructible terrain system... could this allow for tunneling through terrain? Perhaps digging up one area, and dumping it someplace else?

[PolyVox]

How practical is this system for something such as an animated model?

Not very practical, I'm afraid, as there is no support for animated volumes. The system is designed for representing the environment, and it is expected that you will use regular polygon meshes for other objects.

another thing we are working to have is scripted animation. Basically, rather than "fixed" animation, the character moves in accordance to the terrain they are on, actually placing there feet down on the ground and such. (Seen this done before, but it was for a mechanical walker)

That is possible, but it is outside the scope of what the engine handles. You would have to code that functionaliy yourself.

This particular destructible terrain system... could this allow for tunneling through terrain? Perhaps digging up one area, and dumping it someplace else?

Yes, this is basically what it is designed for. It's just a case of deleting voxels in one area and creating them in another.

[yapdakilla]

You know what would be awesome ? You should have 2 planets colliding with each other! WHEN WORLDS COLLIDE !

[nikki]

PolyVox, you should've picked some random 'alien' planet. Destroying the Earth is... Sad.

Anyway, the holes are too 'perfect'. Any chance we could see some shots of some less perfect holes?