***** Update: Now in Game Engine Gems 1 ***** Hey all,
I just wanted to let you know that the new book 'Game Engine Gems 1' features a chapter about the Thermite3D engine as described in this thread. The chapter (titled 'Volumetric Representation of Virtual Environments') is written by myself and covers storage of the voxels, the surface extraction, and the rendering process. Anyone interested in this technology should check it out!
You can find out more about the book at http://www.gameenginegems.com/
***** 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.
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/Thermite-July2009.zip 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: http://www.thermite3d.org/resources/images/screenshots/thermite/techdemo/021.jpg http://www.thermite3d.org/resources/images/screenshots/thermite/techdemo/020.jpg http://www.thermite3d.org/resources/images/screenshots/thermite/techdemo/019.jpg http://www.thermite3d.org/resources/images/screenshots/thermite/techdemo/018.jpg http://www.thermite3d.org/resources/images/screenshots/thermite/techdemo/017.jpg
************** End of July 2009 Update ************
*** Update - Rigid Body Physics - 13/4/08 ***
I have updated the tech demo to show the new integration with Bullet - this allows rigid body physics in a fully destructible environment. The things you might want are:
New Demo: http://www.david-williams.info/linked_from_web/PhysicsDemo/ThermitePhysicsDemo.zip Runtime (install if you have a problem running the demo): http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en
YouTube Video: http://www.youtube.com/watch?v=qmZrdBBQThk Higher Quality Video (Encoded with XViD): http://www.david-williams.info/linked_from_web/PhysicsDemo/RigidBodyDemoXVid.Avi
Hi Guys, this is the only forum I know of which discusses Voxel based game engines (i.e. VoxLap) so I thought you might be interested in one I have been working on myself - especially as I've seen people interested in a hardware accelerated version.
You can see my work here: http://www.ogre3d.org/phpBB2/viewtopic.php?t=27394&start=0
It's written as an extension to the Ogre 3D graphics engine. It lacks many of the cool features of Ken version (such as geometry which falls away once it's cut out) but hopefully all these things are to come.
Hope you like it!
Edited by esuvs at
Awesoken at
Re: My Voxel Game Engine
Nice screenshots. Unfortunately this is all I get:
C:\Demo>VoxelSceneManagerDemo.exe The system cannot execute the specified program.
System info: P4-3.6 HT, 1GB, Radeon X800 XT (256MB), XP Home (SP2), DX9
Any ideas?
esuvs at
Hmmm... odd. So can you see the .exe? What happens if you run it through explorer rather than the command line?
Otherwise maybe download again - perhaps the file was corrupt?
I haven't heard of anyone having this problem...
Awesoken at
No luck. I think your distribution is missing some DLLs. FYI: I do not have Visual C 8.0. Searching for the error message, this page may have a clue: http://blogs.msdn.com/nikolad/articles/427101.aspx
esuvs at
Ok, well I've built a new version using Visual Studio 2003 rather then 2005 Express. I think I heard somewhere that if you use express your client might need to install a redistributale package but I haven't had this problem until now.
You can get the new version here: http://www.david-williams.info/Thermite-current.zip
Let me know if it works. Be aware that if you load 'output.volume' rather thanthe default volume you actually start inside solid material - press 'c' to turn off collision detection or just shoot your way out :)
Awesoken at
Yup, your demo works now : ) The frame rate is quite good for that resolution. It would be cool to see how Voxlap maps (1024x1024x256) perform in your engine. (There's a format description in VXLFORM.TXT, included with the Voxlap source code).
I was reading through your thread on the ogre3d forums and I want to clarify something. In one post, you say:
Though I believe he exploits vertical coherence in some way such that it's not completely generic. For example, i'm not sure if he can roll his camera through 90 degrees (though whether this really matters is open for debate).
Actually, Voxlap has no limitations with camera orientation. My demos simply don't use roll.
esuvs at
Great, I'm glad it works now :)
I haven't really done much in the way of performance testing but yes, it seems fine at the moment. And the speed should be less dependant on resolution than it would be in a raycasting approach because I use marching cubes. This may change when I use fancy materials with bumpmapping, etc, though.
However, at the moment the maps are quite small (256x256x256) and it will struggle with anything larger because marching cubes produces a frankly ridiculous amount of triangles. I hope that I can address this using level of detail meshes but I don't yet know how well this will work...
The marching cubes and raycasting approaches are very different and (as i said in one of my posts) there are a lot of advantages of each. I really don't know which one makes the most sense in the long term - eventually i'll try to make a nice architecture where you can plugin renderers to compare them. But I have plenty to do before then :)
Jinroh at
Nice Screenshots esuvs, your engine like Ken's looks delightfully Chaotic and Destructive. Keep up the nice work.
Hazard at
Great work esuvs! :) Your demo motivated me to finally implement voxel support into my own Direct3D engine (which is completely written in .Net) a few days ago. It's a very early state and still has many flaws, but i'd like to show my progress so far.
Some facts on my implementation: - uses Marching Cubes (as usual) to create the polygonal structure - the resultung model can freely be moved, scaled, rotated, etc. like any other model - mutiple voxel volumes in one scene are possible - size of voxel volumes can be chosen freely - voxel manipulation in realtime (however the impact on the framerate is still quite high) - polygonal model automatically gets recalculated in modified sectors
cons: - horrible loading times of bigger voxel volumes - high polygon count (4.107.678 triangles on ken's untitled.vxl) - high memory useage (haven't got any compression yet and also save color values for all voxels, not just surface voxels) - bad performance (haven't done optimizations yet. A C++ implementation would most likely be much faster)
Embedding the voxel volumes into a polygonal engine through some polygonization method (like marching cubes) seems to be the most promising method for voxels currently. The resulting model doesn't look too blocky and you've got plenty of room for further improvements of visial quality and performance with some more advances techniques. A free positioning of multiple freely scales voxel volumes may also be used to increase performance and reduce memory useage. You could build a game level as conventional polygonal model and just add small voxel volumes in places where destructable objects are needed. If you want to build a destructable house, you could do each wall as a seperate voxel volume of a size like 128x32x4 voxels. This would reduce the amount of unused voxel space alot without sacrificing the full destructability... you just won't be able to ADD voxels to those areas not covered by a volume.
Screens of ken's untitled.vxl in my engine (click to enlarge): http://www.megamods.de/_temp/vxl1s.jpghttp://www.megamods.de/_temp/vxl2s.jpg http://www.megamods.de/_temp/vxl3s.jpghttp://www.megamods.de/_temp/vxl4s.jpg
Closeup of the polygonal structure generated by marching cubes: http://www.megamods.de/_temp/vxl5s.jpg
esuvs at
Hazard said at
Embedding the voxel volumes into a polygonal engine through some polygonization method (like marching cubes) seems to be the most promising method for voxels currently. The resulting model doesn't look too blocky and you've got plenty of room for further improvements of visial quality and performance with some more advances techniques. A free positioning of multiple freely scales voxel volumes may also be used to increase performance and reduce memory useage. You could build a game level as conventional polygonal model and just add small voxel volumes in places where destructable objects are needed. If you want to build a destructable house, you could do each wall as a seperate voxel volume of a size like 128x32x4 voxels. This would reduce the amount of unused voxel space alot without sacrificing the full destructability... you just won't be able to ADD voxels to those areas not covered by a volume.
Awesome! It's good to see that other people are working on this stuff. So that level is 1024x1024x256? So far I haven't gone beyond 512x512x512 so I don't really know how well my stuff scales. But as always lets lots of optimisations left to do.
And yes, I agree that combining voxels and polygons seems to be a promising approach. My current plan is to have other objects in the world as conventional meshes and to also allow the addition of static world geometry as you describe. But to an extent this won't be my responsibility as it will come through Ogre.
I must say, I'm very impressed with your image quality - it's very smooth. I've got the lighting there now (I take it you use central difference or sobel for the normals?) but I don't have smooth transitions between adjactent material like I see in your close up screenshot. Something to work on...
Oh, and one other thing, have you implemented any kind of physics? I think it gets interesting in a voxel environment but it's still on my todo list...
Also, I assume you're doing marching cubes in software? Or you have a hardware implementation?
Excellent work, I'll look forward to seeing a website or demo :)
Edited by esuvs at
Hazard at
esuvs said at
Awesome! It's good to see that other people are working on this stuff. So that level is 1024x1024x256? So far I haven't gone beyond 512x512x512 so I don't really know how well my stuff scales. But as always lets lots of optimisations left to do.
And yes, I agree that combining voxels and polygons seems to be a promising approach. My current plan is to have other objects in the world as conventional meshes and to also allow the addition of static world geometry as you describe. But to an extent this won't be my responsibility as it will come through Ogre.
I must say, I'm very impressed with your image quality - it's very smooth. I've got the lighting there now (I take it you use central difference or sobel for the normals?) but I don't have smooth transitions between adjactent material like I see in your close up screenshot. Something to work on...
Oh, and one other thing, have you implemented any kind of physics? I think it gets interesting in a voxel environment but it's still on my todo list...
Also, I assume you're doing marching cubes in software? Or you have a hardware implementation?
Excellent work, I'll look forward to seeing a website or demo :)
I'm glad you like it. :) The images above just use vetex normals (simply the average of all normals of adjacent faces). I'm currently testing another method that calculates an average of vectors pointing to all nearby, empty voxels. The result is extremely smooth (look at the attached screenshot) but loading times increase even further to an unacceptable value. :/ all adjacent faces share their joint vertices, which results in the smooth transition on colored materials.
I haven't got any function yet that checks for severed bunches of voxels and animates them, like voxlap does. The only physics implemented so far is my old particle based physics engine that might be useful for simple animation of debris or projectiles.
The marching cubes are completely done in software. It would be great to calulate them on the graphics card (at least on map loading while no renderig is required), but doing this with shader versions lower than 4.0 is a pain. Doing it with version 4 shaders would be very doable. I've read an NVidia document on how to calculate, generate and render all needed polygons for display of a voxel volume per frame (!!!) in realtime with DX10. The power and flexibility of 4.0 shaders is amazing. Unfortunately i haven't got a DX10 card to check this out.
A demo will come as soon as i got rid of some flaws an optimized it a little more. :)
Do you know a good place to get volume textures? Or a good tool to generate some? I haven't found anything good on the net.
A screen of ken's untitled.vxl with "volume calculated normals" (click to enlarge): http://www.megamods.de/_temp/vxl6s.jpg
esuvs at
Hazard said at
The images above just use vetex normals (simply the average of all normals of adjacent faces).
That's what I was doing originally, but I had some problems. My approach works by breaking the volume down into 'regions' of about 32x32x32 and I generate a seperate mesh for each region. When a region gets changed I regenerate the mesh for only that region. Is that how your approach works? Basically, because adjacent meshes are spereate the normals didn't match in the boundaries and so it was possible to see where the boundaries were. Do you have this?
Basically what I do now is to compute the normals directly from the volume (I think that's what you're getting at with your new approach?). I would strongly recommend checking out Central Difference or Sobel gradient operators (google them...) - they worked very well for me.
Hazard said at
all adjacent faces share their joint vertices, which results in the smooth transition on colored materials.
Ah, right. I don't know how easily I can do that - Ogre seperates materials so it can sort them and minimise state changes. But there must be a way arond it, I'll look into it.
Hazard said at
The marching cubes are completely done in software. It would be great to calulate them on the graphics card (at least on map loading while no renderig is required), but doing this with shader versions lower than 4.0 is a pain. Doing it with version 4 shaders would be very doable. I've read an NVidia document on how to calculate, generate and render all needed polygons for display of a voxel volume per frame (!!!) in realtime with DX10. The power and flexibility of 4.0 shaders is amazing. Unfortunately i haven't got a DX10 card to check this out.
I must admit I'm not really a hardware expert - I got into this after doing software volume rendering at work. But yes, I know that the NVidia 8000 series support geometry shaders which allow the implementation of marching cubes. However, as I understand it you have to regenerate the mesh each frame. But I did hear of some upcoming extension called 'render to buffer' or something which lets you save the mesh from the geometry shader into GPU memory. At which point it could get very interesting... But at the moment mine is all in software as well.
Hazard said at
Do you know a good place to get volume textures? Or a good tool to generate some? I haven't found anything good on the net.
So it sounds like you are having the same problem as me - that the biggest issue is not technical but content creation. There are two issues for me, generating the level volumes and generating 3D textures to apply to the levels. I notice you appear to have some kind of noisy texture applied to your surfaces - I assume that is a 3D texture?
For generating the levels I can maybe help - I've written a converter which takes an Ogre XML mesh file and converts it into a volume. However, the Ogre XML format isn't working great for me so I might move to COLLADA - at which point it might be more useful for you. Or just look at my (currently poor!) code to see what I'm doing. Look at my Ogre3d forum post for Subversion details...
For generating the actual 3d textures I'm currently stuck - I haven't found much in the way of tools and am reluctant to write my own. But a couple of things - firstly I found this:
Secondly I think it may be possible to use the material editor built into most 3D modeling applications. I think if you can make a nice material and then render a series of planes through that material you should be able to build a 3D texture. Maybe it can even be scripted... I think the biggest problem here is that the textures probably aren't repeating.
Oh, and if you've ever use ATI RenderMonkey it has an 'export to volume texture' option. But i haven't tried it and wasn't convinced it would make things that easy.
esuvs at
*** Update - Rigid Body Physics ***
I have updated the tech demo to show the new integration with Bullet - this allows rigid body physics in a fully destructible environment. The things you might want are:
New Demo: http://www.david-williams.info/linked_from_web/PhysicsDemo/ThermitePhysicsDemo.zip Runtime (install if you have a problem running the demo): http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en
YouTube Video: http://www.youtube.com/watch?v=qmZrdBBQThk Higher Quality Video (Encoded with XViD): http://www.david-williams.info/linked_from_web/PhysicsDemo/RigidBodyDemoXVid.Avi
I haven't been providing updates on this project as often as I would like but it is still moving ahead. The latest demo shows how both Bullet and Ogre can be updated with new environment data in real time. It's still early in the physics integration stage and I need to make a lot of speed improvements but the potential is definitely there :-)
The project is now really two projects:
PolyVox Library: The underlying library which stores the volume representation of the world and is responsible for generating new meshes when the voxels change. This library is independent of Ogre and the idea is that anyone can integrate it into their own engine.
Thermite Game Engine: An experimental game engine to showcase PolyVox technology by combining it with Ogre and Bullet.
Actually this separation is not quite complete but should be within a few weeks. Note that the code is not easily buildable on either Windows or Linux at the moment (you really have to know what you are doing) but as the separation proceeds and the code gets neater this should change.
Both projects are under the GPL, though I am considering changing this to something more liberal. But I need to think about this some more.
Anyway, let me know if you have any questions!
ConsistentCallsign at
Re: My Voxel Game Engine - Now with Rigid Body Physics
I don't like it. It reminds me too much of Team17's "poxel" engine. I hate compromises. Voxels > poxels > polys :D
esuvs at
ConsistentCallsign said at
I don't like it. It reminds me too much of Team17's "poxel" engine. I hate compromises. Voxels > poxels > polys :D
So what don't you like about it? For me the important thing about voxels is not the way they are rendered, but the things they allow me to do in terms of a dynamic environment. Whether you choose to display them using polygons, raytracing, point-based rendering, etc is really just a detail ;)
ConsistentCallsign at
I don't like that the size of the voxel/poxel volume in the castle demo, is less than 1024x1024x256.
Edited by ConsistentCallsign at
esuvs at
Yes, the volume is currently quite small (256x256x256) though I intend to increase it in the future. However, it is compensated for to an extent by the fact that you can have sub-voxel details. I've managed to implement putting bump maps on individual voxels and hopefully I'll get full relief mapping working at some point.
But yes, it will be interesting to see how much I can increase the size of the volumes.
0xC0DE at
I think it looks awesome! much better then Voxlap (visual speaking) alot less blocky! keep up the good work :)
JonoF at
That's pretty bloody cool. Kind of like GeoMod from Red Faction's engine only more detailed.
esuvs at
Thanks guys! I'm glad you like it. It's under active development so hopefully I have more to show soon.
Hudson at
This is amazing :D
How difficult is this to develop for?
esuvs at
It's pretty tricky at the moment. But the way I see it working is that there will be an in game editor so you can freely toggle between 'play' and 'edit' modes. Changing the material of voxels or adding new ones is no harder than destroying them, so really it's a case of adding the user interface for it. It's on my todo list... but probably not for a few months.
That said, I do have a mesh to voxel converter which I wrote. That was what I used for the castle in the video. It's been a bit abandoned though, and I'll probably get rid of it when the in game editor works.
Edited by esuvs at
esuvs at
For those who are interested in following the development of my engine, I have just launched my project website. You can see it at http://www.thermite3d.org
Of course, I'll continue to post significant advancements in this thread as there is a good voxel community here.
ConsistentCallsign at
Hugo Smits said at
alot less blocky!
Voxlap is actually less blocky since it uses a bigger voxel volume.No matter how hard you try to smoothen out the voxels, you can never fully hide the fact that the castle map in the thermite demo is built with big lego blocks. Worms 3D had the same problem, the voxel volume was too small.
esuvs at
Re: My Voxel Game Engine - Updated July 2009
***** Update *****
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/Thermite-July2009.zip 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: http://www.thermite3d.org/resources/images/screenshots/thermite/techdemo/021.jpg http://www.thermite3d.org/resources/images/screenshots/thermite/techdemo/020.jpg http://www.thermite3d.org/resources/images/screenshots/thermite/techdemo/019.jpg http://www.thermite3d.org/resources/images/screenshots/thermite/techdemo/018.jpg http://www.thermite3d.org/resources/images/screenshots/thermite/techdemo/017.jpg
What didn't work about it? Did it crash, and if so at what point? There should have been a 'logs' folder created - do any of the logs have anything useful (usually the Ogre.log, at the end)?
[Edit:] Oh, and if it didn't start at all, you might need the Microsoft Visual C++ 2005 SP1 Redistributable Package (x86)
Edited by esuvs at
Jinroh at
ConsistentCallsign said at
Holy shit!§ :o :o Those screens look awesome! :o
Never thought I'd say this, but I totally agree with ConsistantCallsign! O_O
Those screens are awesome, that Flaming T Terrain is totally badass. Even if it's flaming. :D
esuvs at
Re: My Voxel Game Engine - Now with destructible Earth
***** 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.
*very* cool - what's the resolution of that Earth?
esuvs at
Atomic said at
*very* cool - what's the resolution of that Earth?
The resolution of the Earth is 512x512x512, which is about the limit of the engine at the moment. I'm currently working on a mesh decimation system which will hopefully let it go a lot further...
esuvs at
***** Update: Now in Game Engine Gems 1 ***** Hey all,
I just wanted to let you know that the new book 'Game Engine Gems 1' features a chapter about the Thermite3D engine as described in this thread. The chapter (titled 'Volumetric Representation of Virtual Environments') is written by myself and covers storage of the voxels, the surface extraction, and the rendering process. Anyone interested in this technology should check it out!
You can find out more about the book at http://www.gameenginegems.com/