Fully Destructible Levels - New website and domain!

[PolyVox]

Thanks, actually I have also experienced the crash when running on my work computer. For some reason it's fine on my home machine It basically happens when your shot leaves the volume - I'll make sure it's fixed before the next release.

For the record, although it's been quiet I'm still very much working on this. Smooth shading now works though it slows the destruction down quite a lot so I have to optimise it andI've done a lot of improvements to the underlying data structures to make them more cache efficient, etc.

I'll be making another release but not for at least a month because I want to see if I can get a paper written about what I'm doing. I'm also trying to build a more impressive test level so maybe I'll post a screenshot when that's done...

[JonasBS]

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

Okay so I don't even download the demo- I think this game won't like Intel Celeron and graphics onboard
But it looks very coo!! I think I will take a look at the code!!

[cypher543]

That's awesome! This would be great for real bullet holes and such. Too bad it takes so long to load, even on a small mesh like that.

[PolyVox]

Thanks It's been significantly improved since the version your looking at. Improvments include:

1) I have a CT scan of a model ship so that makes a more interesting level.
2) Proper sharing of vertices for 1/3 the momory usage and smooth shading.
3) Loads of behind the scenes changes (the realeased version was really hacked together!)
4) I'm currently implementing NormalMapping (with 3D textures as normal maps). Hopefully this hides the changes in lighting on voxel boundaries.
5) You can create voxels rather than destroying them. Or just change thier material allowing you to paint.
6) Oh, and very basic particle system support so that when you shoot the wall it falls away as particles rather than disappearing. Needs lots of work though...

I'll release new screens or a new demo at some point but proably not for a few weeks. I'm trying to write a paper about it first. For that reason I haven't worked on the loading times yet (need to concentrate on graphical nicities for the paper) but there are improvments which can be made.

[sinbad]

Looking forward to it and the paper

[jacmoe]

Any chance that you could change the license to LGPL?

[PolyVox]

Any chance that you could change the license to LGPL?

Yes, there is a chance, but obviously I can't then go back so it's not a decision to be taken lightly. I haven't quite decided where I'm going with this project - I was half planning to commercialise it. But I'm thinking I don't really have the time or resources (and it would be a pretty small), and it might be more beneficial to maximise exposure (i.e. LGPL rather than GPL).
Then, if someone does decide to use it commercially, it would be in thier interest to hire me for what ever changes they want.

So yes, maybe something for the next release but we'll see.

While I'm here, the paper never got written (it was gonna be for EuroGraphics UK). The problem was I couldn't really say exactly where the 'research' was. This killed motivation for the project for a couple of weeks but I'm back on it now

[jacmoe]

Ah, I see.

Good luck with it - looking forward to seeing more of it!

[Alik]

What would it be like to write a raytracer using a voxelized representation of a world (such as the one in this demo)? I don't know the first thing about raytracing, so maybe this has been done tons of times, but it seems to me it would be quite fast - you'd essentially be writing a 3D line drawing algorithm that just traced out a path through cells until it hit something. The point being that the rendering time would only be dependent on the number of pixels being drawn (and the distance from the screen to the objects), not the complexity of the scene. You could address the distance problem by storing the world in an octree-style representation and thereby skip over large empty spaces.

[PolyVox]

What would it be like to write a raytracer using a voxelized representation of a world (such as the one in this demo)? I don't know the first thing about raytracing, so maybe this has been done tons of times, but it seems to me it would be quite fast - you'd essentially be writing a 3D line drawing algorithm that just traced out a path through cells until it hit something. The point being that the rendering time would only be dependent on the number of pixels being drawn (and the distance from the screen to the objects), not the complexity of the scene. You could address the distance problem by storing the world in an octree-style representation and thereby skip over large empty spaces.

It is a posibility. Actually, I got the idea for this project from working in medical imaging doing 'virtual endoscopy' - we take CT scans and do flythroughs through various air-filled structures in the body. However, framerates aren't great, we get about 20-30 fps when filling a 512x512 image (this is on the CPU). We don't fully trace every pixel though, we try to use coherence between adjacent pixels to guess where the surface might be.

Using GPU raytracing this can probably be improved, but then you have to store the volume on the graphics card. This uses space (though there are large continous regions so it probably compresses well) but also means you need to keep the GPU volume in sync with the CPU volume when it changes. I don't really know how hard this is, actually i'm pretty new to GPU graphics.

I do know that Ken Silverman uses software raycasting for his voxel engine:
http://advsys.net/ken/voxlap/voxlap05.htm
And it's very fast. 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).

There are a whole bunch of trade offs. The advantage of a polygon approach is that you easily get subvoxel detail through texture mapping, normal mapping, etc, which I think will be harder through raytracing. When the scene is static it's very fast (and will be better when i put in level-of-detail meshes). Raytracing gives you perfect visibility culling and you don't have to recompute stuff when the volume changes.

Basically it may well be an option, though i'm not intending to try it yet. Maybe once all the data structure are in place differnt rendering approaches can be tried.

[uzik]

Thanks for sharing the source! I was just wondering how I was going
to manage blowing things up...

[PolyVox]

Thanks for sharing the source! I was just wondering how I was going
to manage blowing things up...

No problem, dev work is going very slowly at the moment though, two deadlines in a couple of weeks time.

I've been doing bits and peices on it, it now works with Eihort (though I'm yet to try dynamic manual objects, which I hear could help). Added some mesh smoothing code, though I don't want to do too much on this until I determine what can be done in shaders. I've also moved away from the ExampleFramework, which is hopefully good in the long run but means I've lost functionality in the short term.

Problem is, despite numerous internal improvements, it still looks pretty much the same. I'll release another version once it looks prettier!

[uzik]

I was perusing the code today and read through the reference paper
on marching cubes. The table based implementation should be very
quick.

I assume you intended to optimize by only subdividing a surface as it's
struck by a bullet, and not applying it to every mesh in the scene?

The rubble falling out would come easily if you have a physics
simulation hooked into your code. Instead of deleting the subdivided
cubes inside the spherical damage area just apply a spherical outward
force and you're good.

What was your problem with the result? Since you're
subdividing into square or cubic regions you'd have to make them
pretty small before the jaggy appearance disappeared.
The mesh smooth would probably help a lot. Is it computationally intensive
to do?

Perhaps you can reference the LOD settings and recursively
subdivide just at the edge until you reach cubes of a size
set as the next the level of detail? This would give the edge
smoothness without generating a lot of geometry that doesn't
contribute anything.

Man, this reminds me of infinitesimals in calculus.

[PolyVox]

I was perusing the code today and read through the reference paper
on marching cubes. The table based implementation should be very
quick.

Yeah, it's pretty fast I'm sure it could get faster though, I haven't really profiled to see where the bottle necks are.

I assume you intended to optimize by only subdividing a surface as it's
struck by a bullet, and not applying it to every mesh in the scene?

I'm not quite sure what you mean... The way it works is the volume (currently 256x256x256) is divided into blocks (say 32x32x32) and I generate a mesh for each block. If the data in the block changes the I regenerate only that mesh. So yes, changes to the data only affect the mesh 'locally'.

The rubble falling out would come easily if you have a physics
simulation hooked into your code. Instead of deleting the subdivided
cubes inside the spherical damage area just apply a spherical outward
force and you're good.

Yes, actually I've already half done this. When the voxels are deleted they are replaced by a particle system which sends pieces flying out. Need to see if I can use meshes for the particles though - haven't tried this yet.

The real problem with the physics I think will be detecting the 'floating' regions which result from cutting out supporting material. I haven't thought about this much but it's pretty tough.

What was your problem with the result? Since you're
subdividing into square or cubic regions you'd have to make them
pretty small before the jaggy appearance disappeared.
The mesh smooth would probably help a lot. Is it computationally intensive
to do?

You mean with the mesh smoothing? Actually that was a lie - I'm not really smoothing the mesh at the moment, I'm just averaging the normals of several adjacent voxels so it looks smoother.

The mesh smoothing needs some thought. If I do it on the CPU then it may be slow but only gets done once. If it is done with GPU shaders then it's fast (and can be done per-material) but has to be done every frame.

I heard something about next-gen hardware allowing the results of the geometry shader to be written back to a Vertex Buffer. Sounds great, this might solve the problems.

Perhaps you can reference the LOD settings and recursively
subdivide just at the edge until you reach cubes of a size
set as the next the level of detail? This would give the edge
smoothness without generating a lot of geometry that doesn't
contribute anything.

The system definatly needs LOD. Actually It's quite easy to get from marching cubes - I just take a group of 8 cubes and consider them to be 1 cube, then just generate the mesh for that. Generating the mesh for each LOD should be 8 times faster than generating the previous LOD.

But there are other options - I could ditch Marching Cubes directly and use a different algorithm. There are some which start with a crude approximation and successively improve it. One of the problems with marching cubes it that it generates loads of triangles even for a large flat surface. Other approaches avoid this because they only subdivide a surface if it is curved.

I have a lot of research to do here...

[uzik]

I assume you intended to optimize by only subdividing a surface as it's
struck by a bullet, and not applying it to every mesh in the scene?

I'm not quite sure what you mean... The way it works is the volume (currently 256x256x256) is divided into blocks (say 32x32x32) and I generate a mesh for each block. If the data in the block changes the I regenerate only that mesh. So yes, changes to the data only affect the mesh 'locally'.

I was thinking of trying to subdivide the object only if it was damaged.
I think the physics engine ODE will return a structure telling you where
the points of collision between two objects are. If you could read that
you could subdivide the object being struck into parts that aren't
impacted and parts that are. If you shoot at a brick this would allow
you to break the brick into 9 objects instead of 32. There would be
one square area in the center approximating the impact area, and
8 other areas around it. You could further subdivide that to get a
smooth round damage area. Then take the damaged faces and
apply a spherical outward force to them to make them explode
outward.

Good luck with it. If I get any code written I will certainly send it your
way

[PolyVox]

Well if your interested in volumetric representations of the world you should check out this post, espessially the links in the first reply:

http://www.gamedev.net/community/forums ... _id=439081

Ken Silverman's VoxLap Engine is very impressive

[ArchAnemone]

esvus, have you made any more progress on this? It looks very promising! Please continue! : )

[PolyVox]

Don't worry, it's still progressing

The problem is I have been spending a lot of time on architecture stuff - i.e. porting to Eihort, leaving the ExampleFramework and making my own, porting to CMake (with help), improving the underlying data structures, etc. I haven't posted much more becase there haven't been any cool new images to show off, though a lot has changed internally.

However, I have got half a converter working so Blender can almost be used to make levels. When this works (give it a week or two) there will be something different to show off

On that topic, if anyone can answer this question it would be great - http://www.ogre3d.org/phpBB2/viewtopic.php?t=30863

[uzik]

About attaching data to your scene objects:

Ogre provides a method called SetUserAny (I think). you can associate a pointer with your Ogre objects and you can use that to point to your associated user data. Search the api help document and you'll see it

[PolyVox]

About attaching data to your scene objects:

Ogre provides a method called SetUserAny (I think). you can associate a pointer with your Ogre objects and you can use that to point to your associated user data. Search the api help document and you'll see it

Thanks, but actually I'm talking about a way of attatching data (flags, numbers) to meshes in blender - this data would then be used by my converter to generate the volume but wouldn't be seen by Ogre. For example, if you create a mesh in blender and want to generate a volume for it you need yo know a couple of number indicating the material to use inside and for the surface, maybe a letter indicating whether smoothing should be used or something. At the moment I attatch a material with a name like "1_3_s" which I then parse in the converter to get the information.

This works perfectly well, but I just wondered whether there was a better way to do it. I'm only using the material name (none of it's other properties) so I just wondered if I could use the mesh name and save the level designed from attatching materials to everything. But if not it doesn't really matter...

[PolyVox]

**Update**

Right, I thought it's about time I provided an update on this project. The code has been moved to Sourceforge and is available by following the instructions on this page:

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

It's still very much in the alpha stage, but new features since the initial release include:

• Mesh converter to build volumetric scenes from Ogre .mesh.xml files
  Improved materials including support for bumpmapping
  No longer built on ExampleFramework
  Moved to Ogre 1.4
  New CMake build system - thanks to milliams
  Linux version
  Lots of internal changes - unfortunatly you can't see these!

The code includes a 'default' volume - generated at runtime - but can aso load a volume from disk provided it is placed in the program's bin directory and named 'output.volume'. An example volume is here:

http://www.david-williams.info/output.zip

Here's a couple of screens of the output from the conveter - before and after destroying parts...




It's still a long way from being ready for use but I'd be interested in whether you can get it to compile and run (although expect crashes...). I've ben pretty lame with updating this thread so I'll try to do it more frequently in the future - maybe one a week or so.

[Aladrin]

Your makefile checks for boost, but doesn't check for boost-program-options.

After installing that, I get:

Code: Select all

/home/william/src/thermite/trunk/Xml2Volume/source/ConverterVisitor.cpp: In member function ‘void ConverterVisitor::recursivelyWriteTriangleCentres(const Triangle&, unsigned char)’:
/home/william/src/thermite/trunk/Xml2Volume/source/ConverterVisitor.cpp:248: warning: passing ‘double’ for argument 1 to ‘void ConverterVisitor::writeVoxel(unsigned int, unsigned int, unsigned int, unsigned char)’
/home/william/src/thermite/trunk/Xml2Volume/source/ConverterVisitor.cpp:248: warning: passing ‘double’ for argument 2 to ‘void ConverterVisitor::writeVoxel(unsigned int, unsigned int, unsigned int, unsigned char)’
/home/william/src/thermite/trunk/Xml2Volume/source/ConverterVisitor.cpp:248: warning: passing ‘double’ for argument 3 to ‘void ConverterVisitor::writeVoxel(unsigned int, unsigned int, unsigned int, unsigned char)’
/home/william/src/thermite/trunk/Xml2Volume/source/ConverterVisitor.cpp: In member function ‘void ConverterVisitor::parseSubmeshOptions(std::string)’:
/home/william/src/thermite/trunk/Xml2Volume/source/ConverterVisitor.cpp:307: error: ‘split_winmain’ was not declared in this scope
make[2]: *** [Xml2Volume/CMakeFiles/Xml2Volume.dir/source/ConverterVisitor.o] Error 1
make[1]: *** [Xml2Volume/CMakeFiles/Xml2Volume.dir/all] Error 2

There's quite a few more warnings before that. I truncated it because they were all pretty much the same thing, and none were actual errors.

Kubuntu Feisty 7.04 32-bit. P4 3.2ghz, nVidia 7800GTX.

[PolyVox]

Your makefile checks for boost, but doesn't check for boost-program-options.

I don't think it's necessery to check for the diferent parts of boost individually. Actually I suspect it has found program_options or it would have complained beore this point about not finding the header file. More likely the 'split_winmain' function which it can't find is windows only - hardly suprising but an oversight on my part. I'll fix it in a couple of hours when I get to uni.

And yes, there's a lot of warnings! I think they are mostly casting - I keep meaning to increase the warning level in visual studio and fix them...

[Aladrin]

No, I had not installed boost of boost-program-options. It complained of the header file being missing, so I installed boost-program-options. After that is when I get that error. I should have been clearer about that.

As for checking for the parts... Isn't the point of the configuring (cmake, in this case) to check for things that might be missing and warn the user? It seems silly to have something that might not be installed and not check for it. Kubuntu (and the other flavors) let you install many boost libraries seperately. I had to specifically add boost-program-options.

Seems to me it'd be a lot easier to explain what's missing in the configuration process than get a lot of questions about 'it says boost_program_options.hpp is missing!' (Or whatever that file was.)

At any rate, I think this is a really neat project and I'm glad to help out trying to compile it.

[PolyVox]

Ah, so it's actually two problems. Firstly CMake doesn't test whether components of CMake are properly installed, and secondly - even if it is installed - the split_winmain function doesn't exist on Linux.

Well the second problem is fixed - I just copied the function into the source tree and as far as I can see there's nothing windows-only about it. Try updating and compiling again...

Don't know about the first problem yet - the boost detection script is actually part of CMake so that's where it should be fixed. Later on I'll be using other boost components anyway (and I believe its a requirement for Shoogoth?) But I'll try and make it do something sensible..

Thanks for your helps btw, I'll try and get Linux installed in the next few weeks so I can make sure I don't break it. I know it worked before boost integration but hadn't tested it since.