Fully Destructible Levels - New website and domain!

[PolyVox]

***** Update: New website and domain *****
After a long quiet period I can now announce that this project has moved to a new website and domain! You can find full details and downloads at http://www.volumesoffun.com. In particular you should see this page.

Up until this point there have been two parts to the project - the PolyVox voxel terrain library and the Thermite3D engine which uses it. Going forward the focus will be shifted to PolyVox only, although we also have a game built on PolyVox which will be announced soon. It uses Ogre, so you'll hear about it here

Latest screens from projects using PolyVox:



***** End of Update *****

***** Update for November 2009 *****
Hi all, it's me again. I just wanted to share with you the latest updates to my project.

Firstly, I have decided to switch to the zlib license. This is much more permissive that the GPL which I was using previously, and allows commercial use amoung other things. I have updated SVN with the new license and will do the website when I get a chance.

Secondly, I have been preparing a new demo which will accompany an article I have been writing about voxel-based game engines. I would therefore like to invite people to test it just to make sure it works on other computers. It demonstrates very basic editing of voxel based terrain. Please read the readme file for instructions.

You can download the demo here: Terrain Editor Demo
If it won't run you might need this: Visual C++ Redist

And now the obligatory screenshot of the terrain editing in action:




Hope you like it!
***** End of November 2009 Update *****

***** Update for August 2009 *****
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.
************** End of August 2009 Update ************

***** Update for July 2009 *****
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/

Download from here: DOWNLOAD
Source under GPL: SOURCE

Just unzip the file and run the .exe. Controls are:

Mouse: Look around
WASD: Move camera
Left Mouse Button: Destroy scenery(the most important control!)
1-0: Change damage size
c: Toggle collision detection (buggy)

I recommend using the OpenGL renderer as the D3D one may have texturing problems. Also be aware that it takes 10 seconds or so to start up. You also need a fairly good machine/graphics card but hopefully this will improve in later releases...

Like I said, it's a very early release (and the source is really horrible) but hopefully it gives you an idea of things to come.

Merry Christmas!

David

[BRAINLESS]

Wow, and just as I was wondering how to edit meshes directly in Ogre... must be my lucky day!

[edit]
perhaps not, I don't think this is what I was looking for, hehe
[/edit]

[Levia]

Nice job!

[yuriythebest]

wohhoho! now there's something. Don't know about the frame rate in fps games- will be very slow unless it uses some voxel manager where it actually simulates only close by geometry and everything distant and/or inactive are dynamically switched between normal/voxel geometry. Will already be awsome for arcade games and flight sims and more. Again I'm no expert. Awsome, keep this going!

[Kencho]

When a true Worms 3D clone?

[Chris Jones]

wow

definatly keep us up to date with this!

[CheetahShrk]

The demo kept crashing on my comp after I destroyed the layers of the wall right into the last layer.
Its awesome however, would be cool to make some sort of digging game using it.

[Deranged]

Very nice

[bharling]

Really Excellent, reminds me a lot of the technology in 'Red Faction'. Would love to see this continue, and for the record, it seemed to run fine (considering all factors) on my mums p3 2.0, with no 3d card.

[max621]

Digging game using big machines would be sweet

[PolyVox]

Thanks guys! The positive feedback means a lot

wohhoho! now there's something. Don't know about the frame rate in fps games- will be very slow unless it uses some voxel manager where it actually simulates only close by geometry and everything distant and/or inactive are dynamically switched between normal/voxel geometry. Will already be awsome for arcade games and flight sims and more. Again I'm no expert. Awsome, keep this going!

The level consists of one big volume (currently 256x256x256 voxels) which is split into blocks (I think these are currently 32x32x32 but need to check/experiment). At the moment the meshes for each block are computed on startup and only recomputed if the geometry changes. But with a bigger level I probably can't keep all meshes in GPU memory all the time - some kind of least recently used appraoch will be required. And I believe techniques like LOD can still be used to save memory and improve performance.

]When a true Worms 3D clone?

Its awesome however, would be cool to make some sort of digging game using it

I haven't really decided what kind of game to make. I was originally thinking Worms3D but I've also been thinking about some kind of Descent style game (apparently that's what Geomod was originally designed for) or an FPS. Maybe a puzzle game like lemmings in 3D.

It definatly opens some new options, rather than destroying scenery it's just as easy to create it. At the moment, whereever you click it creates a sphere of 'air' but it could instead create a sphere of 'brick'. Could be an interesting capture-the-flag game where you build your own defenses whilst destroying your opponents?!

Really Excellent, reminds me a lot of the technology in 'Red Faction'. Would love to see this continue, and for the record, it seemed to run fine (considering all factors) on my mums p3 2.0, with no 3d card.

That's good to know I really haven't focused no optimisations yet so I hope I can get some more out of it...

I'm certainly intending to carry on with this. My future tasks are roughly:

1)Optimise and fix all my bad code. Hence allow loading of bigger levels containing more materials
2) Create some nice materials with bump/normal/displacement maps. Hopefully this can get rid of the jagged edges you see. Play around with lighting approaches again to get smoother surfaces.
3) Integrate particle systems so that stuff doesn't just vanish but instead lts of rubble flies out.
4) Detect when material is no longer supported and have it fall to the ground rather than just hanging there.
5) Lots of other things!

Anyway thanks again for the feedback, must head to bed now or santa won't come...

[johnhpus]

Could be an interesting capture-the-flag game where you build your own defenses whilst destroying your opponents?!

I think that's a seriously good idea and could be a lot of fun.

The speed of the demo varied on my computer from ~100 to ~300 frames per second. It also eventually crashed.

I know voxels lost the war to normal geometry back in the day, but I've always loved the concept and hope it will make a comeback.

[Oogst]

Wow, this is quite fun! The framerate fluxtuates heavy on my computer, though. When I am not doing anything, it is around 90fps, while it drops to 30fps when I am shooting around. I so far only new the tetrahedron-approach and the boolean-approach to destructable geometry, nice to see something else that also works. And also nice to see some alternative use of voxels outside direct graphics rendering.

...
2) Create some nice materials with bump/normal/displacement maps. Hopefully this can get rid of the jagged edges you see. Play around with lighting approaches again to get smoother surfaces.[
...

Why not just use smooth shading? This not only makes the jagged edges much less visible, but can also lower your vertex count extremele. In complex scenes, vertex count is quite important for performance (although I suppose your program is CPU-bound and not GPU-bound and therefore this probably does not matter for this application).

By the way, just thinking around: would it be possible to save the voxels into textures and then use a dx10 geometry shader to generate or update the meshes from the voxels?

[yuriythebest]

downloaded & tried the demo- some awsome stuff. One question- where is the level used here stored?

In the future please fix the freezing bug when you shoot too far into the cement and make a .mesh->voxel converter/loader thingy. Would be totally awsome to try out destroying your own models.

The performance-wize on my p4 3.06Ghz nvidia n6600 256mb and 1gb ram at 1280*1024 it works at 60-110fps and at 800*600 at 180-220 fps

awsome stuff once again

[Project5]

I get excellent performance here, but also get freezes if I try destroying geometry too close to the outer wall.

--Ben

[HexiDave]

VERY cool. You get 100 extra cool-points for getting the camera to bang against the geometry properly - digging into the wall was pretty fun

[Kamazy]

That's really alsome. The closest i'v seen to this is "worms 3d" but this is way better.

[tera4d]

I like this very much
But my pc doesnt like it
I get only 30 fps with 640x480 and even worse when i am shooting it srops to 3 fps
These are my specs:
Amd Athlon XP 2800+ (3.0 ghz)
512 mb-ram ddr2
Nvidia Geforce FX 5200+ (128 mb) * yes i know my 3d card is the problem that card sux so much its to freaking slow.
But other than that it rox

[PolyVox]

Could be an interesting capture-the-flag game where you build your own defenses whilst destroying your opponents?!

I think that's a seriously good idea and could be a lot of fun.

Well I think it can go a lot further... In image processing there are operation known as dilation and erosion which add a layer to or remove a layer from a surface. So the geometry can 'grow'. If you constrain this so it only grows into places where it existed at the start of the game then you have geometry which slowly 'heals'.

Or remember in Worms when you use napalm and it burns through the terrain? You can see that's easy in a 2d game but it should also be easy in 3D using voxels. If one voxel is on fire you can easily find it's naighbours and allow the burning region to grow by 1 layer per second or something. I'm sure there's loads of ideas i haven't thought of. Acid maybe?

Why not just use smooth shading? This not only makes the jagged edges much less visible, but can also lower your vertex count extremele. In complex scenes, vertex count is quite important for performance (although I suppose your program is CPU-bound and not GPU-bound and therefore this probably does not matter for this application).

That should definatly be possible, but there are some catches. As I scan through the blocks to generate the mesh I create a list of polygons but never maintain any connectivity information - I just add each polygon to the back of the vextex/index list. This means that firstly I'm using 3 times as much memory for the meshes as I should be but also means I never get a chance to do any normal averaging. This is definatly something which needs to be fixed because memory is likely to be a problem in large environments.

However, I have another idea for the lighting and would like feedback on this as I have zero experience writing pixel/vertex shaders. Basically it may be possible to use an image-based approach to lighting. In this method I wouldn't pass any normals into the card at all - instead I'd just pass in the geometry and, in the pixel shader, compute the normal for a given pixel by unprojecting it and it's neighbours and using a central difference approach to gradient estimation. I would then like to run some kind of low pass filter over the 'normal image' to shooth it. I believe this approach is generally possible in compter graphics but don't know if it's possible on GPU's. Is it obvious/impossible/crazy? The main benifit is it would save on storing normals in GPU memory and may give a smooth image.

By the way, just thinking around: would it be possible to save the voxels into textures and then use a dx10 geometry shader to generate or update the meshes from the voxels?

Yes, I believe this has a lot of potential. Someone else pointed this out towards the end of one of my last posts and included a link to an NVidia presentation about it. Have a look at the previous post here:

http://www.ogre3d.org/phpBB2/viewtopic.php?t=26291

VERY cool. You get 100 extra cool-points for getting the camera to bang against the geometry properly - digging into the wall was pretty fun

Actually it's pretty trivial to do collision detection against voxels, you simply check your camera position in the 3D array to see if that position is occupied. I have zero idea how to do physics in this kind of environment though :-S

For those experiencing performance problams, I haven't done any benchmarking so I don't know where the bottlenecks are. Most likely everywhere But refactoring, optimising, and improving code quality will probably be the first thing I do. Hopefully that will give some improvements.

[Oogst]

...
However, I have another idea for the lighting and would like feedback on this as I have zero experience writing pixel/vertex shaders. Basically it may be possible to use an image-based approach to lighting. In this method I wouldn't pass any normals into the card at all - instead I'd just pass in the geometry and, in the pixel shader, compute the normal for a given pixel by unprojecting it and it's neighbours and using a central difference approach to gradient estimation. I would then like to run some kind of low pass filter over the 'normal image' to shooth it. I believe this approach is generally possible in compter graphics but don't know if it's possible on GPU's. Is it obvious/impossible/crazy? The main benifit is it would save on storing normals in GPU memory and may give a smooth image.

I am not sure whether it is exactly what you want to do, but I think you can just render positions to a RenderTexture and then do some post processing to generate normals from these positions. This is by all means possible, although I think to get a good result, you will need a floating point RenderTexture, because 8 bits to store depth is probably not enough for good quality. What you would be doing would be like an advanced form in defered shading, I think, which is in the Ogre demo's. Note that this method will probably be very expensive. I do not think you will be able to get framerates anywhere near to what yoy are achieving now, but I am not sure. I do not know that the defered shading demo has a terribly low framerate on my computer.

[PolyVox]

I am not sure whether it is exactly what you want to do, but I think you can just render positions to a RenderTexture and then do some post processing to generate normals from these positions. This is by all means possible, although I think to get a good result, you will need a floating point RenderTexture, because 8 bits to store depth is probably not enough for good quality. What you would be doing would be like an advanced form in defered shading, I think, which is in the Ogre demo's. Note that this method will probably be very expensive. I do not think you will be able to get framerates anywhere near to what yoy are achieving now, but I am not sure. I do not know that the defered shading demo has a terribly low framerate on my computer.

Well I just skimmed through some slides on defered shading and yes, that looks like what I'm talking about. Though none of the slides mention generating the 'normal image' from the 'position image' but that should be posible. Maybe kills an already slow technique though. But i'll definatly give it a shot (Though not for a while!) Thanks!

[PolyVox]

downloaded & tried the demo- some awsome stuff. One question- where is the level used here stored?

Currently it's not, it's generated at run time (in Volume::generateLevelVolume2()). The same is true for the 3D textures (OgreTest.cpp, createBrickMaterial()).

In the future please fix the freezing bug when you shoot too far into the cement and make a .mesh->voxel converter/loader thingy. Would be totally awsome to try out destroying your own models.

Actually I haven't seen this freezing bug but several people have mentioned it. But i'll have a look, it'll probably go away when I improve the code.

As for the loader, I guess I'll write a blender exporter or a COLLADA importer. This can certainly be done to define the shape of the levels but defining materials might be more tricky... Also should probably allow some kid of in-game editing for finer control.

[Oogst]

(...)
Well I just skimmed through some slides on defered shading and yes, that looks like what I'm talking about. Though none of the slides mention generating the 'normal image' from the 'position image' but that should be posible. Maybe kills an already slow technique though. But i'll definatly give it a shot (Though not for a while!) Thanks!

Defered shading usually stores the normal it gets from the geometry, so you are right that you cannot copy that step. However, I think it should not be too hard to generate normals from positions, as you can just read some surrounding positions and consider these to form a plane. I guess it would require some nice solution to detect whether a neighbouring position is on the same surface or another object in another distance, which you would not want to take into account.

[sinbad]

Nice job

[CK_MACK]

really cool. I too experienced the crash when digging to deep.

Thanks for sharing it.

MACK