Fully Destructible Levels - Now zlib license and new demo

[PolyVox]

I think you slightly misunderstand - at the moment I do render polygons. I store a volumetric representation and generate a surface mesh from it when the application loads. Then, when the volume changes, I regenerate that part of the mesh to keep it in sync. I think that's exactly what you're suggesting?

The main reason I say it won't look as good as modern engines is that it's hard to generate meterials (you'll notice the ones in my screen shots are quite plain...). I can't use UV coordinates because it is hard to know what they should be when you are generating polygons on the fly. Instead I use UVW coordinates which are easy to generate but require 3D textures. And it's making these 3D textures which is the hard part as I don't know of any tools (ideas for this appriciated!).

That said, the paper is extremely interesting. I discovered this company recently:

http://www.pixeluxentertainment.com/

and thier stuff looks awesome. I believe the paper you gave me describes what they are doing. You should definatly check out the videos on thier page (but again note there is no UV mapping - maybe not a coincidence!).

I am definatly interested in integrating physics into this at some point so I will have a read of that paper. There are some advantages to doing physics in this environment, but I suspect there are problems too!

[PolyVox]

In fact, they explicitly mention 3D textures and 3D shaders on this page...

http://www.pixeluxentertainment.com/tech.htm

Presuambly they have a nice tool for making them. It's not that hard, procedural texture generators feature in most 3d modelling applications but I haven't got a way to export those yet. Plus I think they tend to be non-repeating, whereas I need repeating ones to make good textures.

[Alik]

I'm sorry, I miscommunicated. What I meant was that, rather than using the Ogre head mesh to generate voxels, and then using the voxels to generate polygons, instead break down the polygons in Ogre head mesh itself and embed them in the voxels you generate. So, the exact polygons from the Ogre mesh persist, and are split up when the voxels they are embedded in break. So in the case of the model with no voxels removed, it should look exactly the same as the plain rendered Ogre head mesh. Does this make sense?

Yes, Pixelux is interesting, but they are too slow right now for really interesting dynamics in real time. But if you want to see better videos of them here they are:

http://www.lucasarts.com/media/games/th ... ed/dmm.mov
(from http://www.lucasarts.com/games/theforce ... ology.html)

http://video.google.com/videoplay?docid ... ts+physics

http://www.youtube.com/watch?v=fWpmQzYWI44

Edit: It looks like most of these videos are now available through Pixelux's links, so you've probably seen them already, but I'll keep them in case you haven't. (When I put the list together their website did not have links to these.)

Alec

[Chaster]

[quote="esuvs"]
The main reason I say it won't look as good as modern engines is that it's hard to generate meterials (you'll notice the ones in my screen shots are quite plain...). I can't use UV coordinates because it is hard to know what they should be when you are generating polygons on the fly. Instead I use UVW coordinates which are easy to generate but require 3D textures. And it's making these 3D textures which is the hard part as I don't know of any tools (ideas for this appriciated!).

/quote]

You've probably already seen this (and maybe it's in this thread already..) but Google for "3d texture generation" brought up:

http://3d-texture.qarchive.org/

Chaster

[PolyVox]

I'm sorry, I miscommunicated. What I meant was that, rather than using the Ogre head mesh to generate voxels, and then using the voxels to generate polygons, instead break down the polygons in Ogre head mesh itself and embed them in the voxels you generate. So, the exact polygons from the Ogre mesh persist, and are split up when the voxels they are embedded in break. So in the case of the model with no voxels removed, it should look exactly the same as the plain rendered Ogre head mesh. Does this make sense?

Ah, right, I see. Well I believe what your saying makes sense and could be done - the initial scene would then be exactly the same as the converted model. The problem comes when you start destroying it, the triangles from marching cubes wouldn't line up with with the initial triangles which would cause cracks. I expect a way could be found to get around this but I don't know how easy it is.

Your approach would also allow the UV coordinates to be extracted from the model - actually this is probably it's biggest advantage. But again, once you start destroying you can't generate texture coordinates which will match.

The idea is interesting though, it makes me wonder if maybe you could not do the initial voxelization at all. Maybe you just keep the original mesh, and as parts get destroyed you just voxelise that region, and then generate the new mesh for that region leaving the rest of the original mesh intact. Something to think about...

You've probably already seen this (and maybe it's in this thread already..) but Google for "3d texture generation" brought up:

Actually I haven't seen that particular program, but I've seen some similar ones. The problem is, most programs which claim to generate 3D texture actually mean they generate 2D textures for applying to 3D models. It appears to be the same for that program, but there is a trial so I'll have a look...

[Alik]

The problem comes when you start destroying it, the triangles from marching cubes wouldn't line up with with the initial triangles which would cause cracks.

Hence the paper I referenced - http://graphics.ethz.ch/~mattmuel/publi ... gi2004.pdf . That should take care of updating the mesh as voxels are destroyed. No marching cubes required.

[broli]

^ I actually stumbleded on that same paper some days ago, good idea but mostly gibberish to me

[Alik]

Yeah, it's pretty confusing. I wish they published source code.

[PolyVox]

Ok, I have now read (most of) the paper - it's very interesting but different to what I'm doing. For their approach they basically build a model out of cubes which corrsponds to the original mesh, keep both of these representations in memory at the same time and when they deform the underlying cubes the surface mesh is updated to match it.

In some ways it's quite similar to Blender 'Lattice' tool, for those who are familiar with it. The lattice tool in Blender lets you add a cubic 3D grid to a mesh - as you deform the grid the mesh is modified accordingly. However, the work in the paper goes further in that you can actually break the 'lattice' ino several parts and the algorithm generates the polygons lying along the break.

The problem is, there's a real pysics engine at work here and I sense it is quite computationally expensive. In Figure 8 they show deformation of a bird - there's only a few hundred cubes being used here.

In contrast, in my scene manager the voxels never move - the simply change material from 'solid' to 'air' when they are destroyed. This means there is no overhead of physics simulation which is fortuate because there are currently over 16 million voxels in play (though not all being rendered!) and I expect this to rise past 1 billion in future versions.

I think there is definate scope for integration of the two technologies in a later version - although the world is currently destructible any objects in it are expected to be normal Ogre meshes. It would be great if these were destructible too - this is what the paper could accomplish

Also, at the moment when you 'cut out' a chunk of solid it justs floats there. Later on it will fall - but it would be nice if if broke in to pieces on impact too...

Ok, I'm getting carried away, there's a lot of work here!

[Alik]

OK, that makes sense. I was just meaning, maybe you would want to keep the mesh, and then when a voxel is removed use the method in the paper to effectively do a CSG operation to delete the relevant volume and generate covering polygons. But you are right, it may be too slow. Though the reason they have the low number of cubes in their example of the bird is that the physics simulation is slow, whereas you would not need any physics simulation.

[PolyVox]

Ah, I've just found that you are behind this post:

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

That soft body stuff looks really cool But unfortuantly I can't get to www.realmatter.com to try the demo - is it down? And did you write a paper for it in the end?

[Alik]

Yeah, that's my stuff - thanks for the compliment! I'm actually working on implementing the geometry-splitting paper I mentioned for that project. And yes, a paper did come of it, though sadly I had to switch away from using Ogre (I rewrote the program starting from a colleague's codebase, which was straight OpenGL) so there won't be any more Showcase postings. The RealMatter website was taken down to avoid jeapordizing the double-blindedness of the paper's review process, but you can still get the demo at http://www.realmatter.com/files/RealMat ... icDemo.zip , though some people report that it crashes on their computers.

But to stay on-topic, I'm really looking forward to seeing where you take this project; I think it's pretty interesting and you could definitely make some fun applications. I think CSG is probably best for destroying scenery where things just get removed, but for applications where voxels burn, fall, move around, etc., your approach would be the only way of doing it.

[PolyVox]

Wow, that 's good fun, reminds me of the game 'House of the Dead', though i guess that was precomputed.

Basically I think the two techniques are perfect complements to each other. My approach handles only the world geomentry but is fast and works with millions of voxels, while your approach provides more realistic breaks and physics but operates at a much smaller scale.

I will definatly look into it further - I think it would be great if a chunk of world geometry could be seperated using my approach, then converted into a mesh so that it can fall to the floor and shatter using your approach

My plan now is roughly as follows:

Do some refactoring and improve memory efficency.
Increase world size and support LOD
Add the above mentioned detection of when material gets seperated.

At some point I'll be trying to improve the materials too in order to make it look nicer.

[PolyVox]

***Update 1st July***

Hi guys, once again I have gone ages without posting anything so I just thought I'd let you know that this is still alive Some changes:

I'm now calling it 'PolyVox' technology as I think 'voxels' have a slightly negative and misleading interpretation. It's still rendered with polygons after all, and 'voxels' sounds somehow outdated. So this is basically a marketing thing.

I've converted a nice castle model which you can see below.

Added texturing support so it works with 2D textures (which are easier to make) but 3D ones will still be an option.

On-the-fly mesh decimation is partly working but needs some work. It's slightly lower priority right now though.

Check out the screens:




You can read more details and download the latest version here:

http://david-williams.info/index.php?option=com_content&task=view&id=24&Itemid=37

I'm not sure what state the Linux version is in - I've accidently introduced dependancies on boost 1.34 which most distributions don't have yet. Of course, this will be resolved in time...

Anyway I'm away for the next week but I'll try to monitor this thread when I can...

[nikki]

Wow! That looks really cool! Nice work. Keep it up.

And also, seeing that you are working with Vista, I wanted to ask you a Vista related question since I am going to transfer all my stuff to my mom's laptop for the summer vacations, which runs Vista (not the summer vacations, the laptop ): Are there any compilation issues or any things to keep in mind when running, building or using Ogre under Vista?

[randall]

Wow! That looks really cool! Nice work. Keep it up.

And also, seeing that you are working with Vista, I wanted to ask you a Vista related question since I am going to transfer all my stuff to my mom's laptop for the summer vacations, which runs Vista (not the summer vacations, the laptop ): Are there any compilation issues or any things to keep in mind when running, building or using Ogre under Vista?

Ogre works great under Vista

[PolyVox]

Wow! That looks really cool! Nice work. Keep it up.

And also, seeing that you are working with Vista, I wanted to ask you a Vista related question since I am going to transfer all my stuff to my mom's laptop for the summer vacations, which runs Vista (not the summer vacations, the laptop ): Are there any compilation issues or any things to keep in mind when running, building or using Ogre under Vista?

Thanks! Regarding Vista there are a couple of things. I use VS 2005 and had to download a massive update to make it work properly - so test in advance don't leave it until the day before. Also I had some problems with my build system working with the new permissions system. So I just turned the permissions system off Nothing like a proper fix...

[nikki]

Sorry to hijack the topic, but to turn the permission system off, I just have to Disable the UAC feature using msconfig?

[jacmoe]

Looks absolutely great, esuvs!

Regarding Vista:
Yes, do turn off UAC.
And do install the vista service pack for VC. (In addition to the regular sp1, yes).

[PolyVox]

@nikki - I've sent you a private mesage explaining - hope that helps.

[jorrit5477]

I do really love the name of your engine!
And it also looks great!

[PolyVox]

I do really love the name of your engine!
And it also looks great!

Thanks! Actually the name is quite important because, when I say 'voxels' people assume it is in some way similar to games like Comanche and Outcast which rendered using voxels. Actually I still don't quite know what this means - as far as I know those games used raycasting and the levels were heightfields - so not really 'Volume Elements'.

Anyway mine really does store the levels with volumes so 'voxels' makes sense, but it's still rendered with polygons. 'PolyVox' is meant to convey this...

[sinbad]

Really nice You could make a version of Rampart

[PolyVox]

**Update**
Right, after 3 months of silence I thought I should post an update on this. Haven't had as much time as I hoped due to needing to write a very long and boring thesis - but that's out the way now so back to the fun stuff

Anyway, the new feature I wanted to show off is mesh decimation. One of the problems with using the marching cubes algorithm to polygonize a volume is that it produces a huge number of triangles, typically 2-3 per surface voxel. This is potentially a problem, and so the latest version will decimate the mesh on the fly so that it uses fewer triangles without affecting the actual shape of the geometry.

It uses a version of this algorithm: http://kucg.korea.ac.kr/education/2003_2/vip618/paper/decimation.pdf and only decimate flat surfaces (there is no tolerance built in). This means it will not affect organic or natural shapes but is very effective against structures such as wall and rooms.

It's too soon to say how much effect it will have on the frame rate - obviously a lower triangle count is good but there are likely to be more significant considerations such as batching and use of shaders. But it's likely to be beneficial when integrated with a physics engine, when performing shadowing, and probably in other areas as well.

Anyway, here are the new screenshots. They are of a boring cubic room, just because it's the area in which the decimation works best.

1) The original room, without decimation and without wireframe.



2) The original room, without decimation but in wireframe mode. Notice the huge number of triangles.



3) The original room after decimation has been performed. Notice the significant reduction in triangle count.



4) The room after blasting some holes in the wall. Notice that the holes are not decimated because they are round, but decimation is still performed around the holes to try and keep the triangle count as low as possible.



5) As with the previous picture, but now with wireframe turned off.



If you haven't seen my project before and are interested in trying it, I'd still suggest trying one of the earlier demos rather than building from SVN. The reason being that this mesh decimation stuff is supposed to be transparent to the user, so even if you have it you can't actually see it without going to wireframe mode. I may release a new demo at some point but it's not high on my list of priorities.

If you do want to build from SVN it should be possible. Linux users may encounter a bit of trouble but give it a go. I make no guarentees about what the code will do at any given time though...

First (room) Demo: http://www.david-williams.info/VoxelSceneManagerDemo-0.0.1.zip
Later (castle) Demo: http://david-williams.info/index.php?option=com_content&task=view&id=24&Itemid=37

SVN Access: http://sourceforge.net/svn/?group_id=44243

Enjoy!

[betajaen]

Holy pants on fire. That is beyond awesome.