Fully Destructible Levels - New website and domain!

KeAz · Post by **KeAz** » Wed Nov 14, 2007 4:33 pm

Well thanks for the reply. Well when it's "mature" I hope some sort of more open license is available, but I might take a look at it anyway out of curiosity and see if I can help improve it.

milliams · Post by **milliams** » Wed Nov 14, 2007 4:56 pm

I don't know if you noticed PolyVox, but the PolyVoxSceneManager got a mention on the "Community News Update" on the front page of ogre3d.org. Congratulations

PolyVox · Post by **PolyVox** » Wed Nov 14, 2007 6:01 pm

KeAz wrote:Well thanks for the reply. Well when it's "mature" I hope some sort of more open license is available, but I might take a look at it anyway out of curiosity and see if I can help improve it.

Yes, the other reason I go for GPL rather than LGPL is to keep open the possibility of a commercial license when it is more mature. Perhaps a duel licensing scheme like Qt and MySQL use. This seems to give the best of both worlds.

It would be interesting to see how it performs in an online game - the biggest problem of course is keeping the various players in sync as the volume gets modified. Don't know how much bandwidth this requires but if you just transmit the parts of the volume which change it may be possible (and in general the data is highly compressable).

milliams wrote:I don't know if you noticed PolyVox, but the PolyVoxSceneManager got a mention on the "Community News Update" on the front page of ogre3d.org. Congratulations

Yep, thanks Sinbad!

cursedbeast · Post by **cursedbeast** » Wed Nov 21, 2007 6:10 pm

Could I ask what version of boost you built the Xml2Volume tool with? I'm having a absolute hell of a time getting it to run. Fails everytime with the following error....

Code: Select all

terminate called after throwing an instance of 'boost::bad_any_cast'
  what():  boost::bad_any_cast: failed conversion using boost::any_cast
Aborted (core dumped)

My third year project revolves alot around a game with realistic social insect behaviour where I'd like to be able to render easily any tunneling or construction. In your opinion do you think the work you've done would be enough to get me there, as its a bit outside my project to get bogged down in graphics writing the code myself.

Id really appreciate any help you could give

Thanks
Chris Scutcher

PolyVox · Post by **PolyVox** » Wed Nov 21, 2007 6:57 pm

It's built with boost 1.34, but as I recall the only reason for requiring this rather than 1.33 is for the boost::filesystem classes used in the main application. So the converter should also work with 1.33, but I can't be sure.

That said, I'm pretty sure that last time I tried it it didn't work anyway. I think long term I will abandon the converter and switch to an approach where you edit in-game. So you can toggle between 'play' mode and 'edit' mode in a way similar to Sauerbraten.

As for whether you should use my work, you don't want to risk your 3rd year project and so you probably should base you decision on the features available now rather than on what I may add over the next few months. The converter is unlikely to be useful to you unless you fix it, but you should find you can generate simple maps procedurally (terrain, spheres, boxes, etc) without to much difficulty.

You should take a look at the the 'Engine' project which uses the SceneManager and basically fork that. It's pretty basic so should provide an easy starting point. Copy it elsewhere on your harddisk and see if you can play around with it. The interface for the scene manager is pretty basic - there's just a function for loading a volume and a couple of funtions for turning voxels on and off and creating spheres.

I think the only other point you should be aware of is that some things in the engine could be done a lot better with DirectX 10. I will get a compatible graphics card in the next couple of weeks and when Ogre supports DirectX10, some parts of the project will be moved over and may no longer work on older graphics cards. It will depend how difficult it is to leave in support as the engine will work differently internally. So basically I'd recommend you have a DirectX 10 graphics card before committing to the project (Ideally an NVidia, as that's what I test with).

I hope that is of some use, feel free to ask any further questions

cursedbeast · Post by **cursedbeast** » Wed Nov 21, 2007 7:17 pm

Thanks for the extrememely rapid reply...

Interesting stuff.. I think I'll give generating terrain a go and see where I can take it from there. I've managed to get the maps you've generated imported and rendering in my project by looking at the engine code so it's just a matter of generating new terrain.

If that doesnt go well 'll try and go my own way and implement something new, although I'll keep a keen eye on your work.

Thanks for the advice

Cheers
Chris

p.s. Shame your going the DX10 route it'll lock us Linux'ers out of the picture

PolyVox · Post by **PolyVox** » Wed Nov 21, 2007 8:15 pm

cursedbeast wrote:Thanks for the extrememely rapid reply...

Interesting stuff.. I think I'll give generating terrain a go and see where I can take it from there. I've managed to get the maps you've generated imported and rendering in my project by looking at the engine code so it's just a matter of generating new terrain.

It should be quite easy, you can just iterate over each voxel and if it's less than a certain height set it to earth, otherwise set it to air. Then try adding some sine waves for hills, etc. And if you want more interesting shapes then the first chapter of GPU Gems 3 talks about voxel terrain generation. Well worth a read.

cursedbeast wrote:p.s. Shame your going the DX10 route it'll lock us Linux'ers out of the picture

Long term there's no need to worry - OpenGL 3.0 will handle it perfectly well for Linux. It's just that Ogre is likely to get a DirectX 10 render system before it gets an OpenGL 3.0 one.

At the moment my project support of to 256 materials (grass, brick, etc as seen in the castle level). Each of these materials is a separate mesh. However, DirectX 10 supports texture arrays which hopefully will allow me to extact just one surface and still apply all the different textures. This will be faster to extract, faster to render, and much easier for physics engines.

However, it means older graphics cards will be limited to just a single material over the whole world. Not as bad as it sounds though - the NVidia cascades demo uses only one material for all the terrain and still looks great

It's all a bit speculative though - I won't know whether DirectX 10 really brings these advantages until I try it.

cece · Post by **cece** » Thu Nov 22, 2007 12:05 pm

umm, with only one mesh to render, how to render interctively it?
Let suppose you must delete / add some triangles to the current mesh.

In DX9, using vertexbuffers, it's hard update a mesh without reinitializing it.

PolyVox · Post by **PolyVox** » Thu Nov 22, 2007 1:21 pm

Sorry, I wasn't quite clear. At the moment the volume is broken down into cubic regions, and the mesh for any cubic region is always separate from the other cubic regions. So if there are 8x8x8=512 cubic regions then there will be at least 512 meshes. But in the event that there is more than one material in a region (which is the most common case) then the region will have several meshes (one for each material).

The way I envisage it will change is that the volume will still be broken into cubic regions but each cubic region will contain exactly one mesh. If there are multiple materials in the region then this will be handled by texture arrays (allowing multiple textures on the mesh), rather than the current approach of using several meshes to represent the region.

The result will be significantly less meshes (exactly the same as the number of regions), bigger meshes (more batch friendly), and less state changes. This should make it faster, and having less meshes should make it easier to do physics.

But you are correct that the world still has to be broken into these cubic reasons. Firstly for the reason you mention (updating part of the mesh) and secondly to allow clipping against the view frustum.

Edit: Reading the above makes me realise how much I need to actually write some documentation for this engine!

nikki · Post by **nikki** » Thu Nov 22, 2007 2:06 pm

<offtopic>
Wow! PolyVox got an avatar at last!

</offtopic>

PolyVox · Post by **PolyVox** » Thu Nov 22, 2007 2:14 pm

Yep, and it scares me every time I look at it. At least it, er, stands out!

cece · Post by **cece** » Tue Nov 27, 2007 11:04 pm

Hi, it's always me

I think i made a big mistake in my work with normal / gradients.. (pag 5)
I simply calculate it with a cross product of the plane of the surface... Then for adding a bit of smoothing, i simply averaged normals in vertices. (try to explain: if three triangles meets in one vertices i have 3 equivalent vertices positions (and then 3 normals in that point)). I have eliminated the copies of the point and builded a single normal by average..)

Am i completely wrong? When i wrote that project, my knowledge in computer graphics were veeryy little...
I read something about the Sobel gradient, it's the way used in raycasting to find gradient for a voxel (look the 6 neighbors)? when applied to Marching cubes i apply that gradient to every triangle inside my cube???

keep this project up

it's very cool

PolyVox · Post by **PolyVox** » Wed Nov 28, 2007 3:53 pm

You are right that it is probably better to calculate the gradients directly from the volume - it faster than using the cross product (probably) and is smoother. There are many ways to do it but the two most common are the Central Difference method (the simplest) and the Sobel operator (smoother).

For a given point in space you will normally evaluate the gradient at the eight corner voxels and then interpolate the results. But because the vertices from marching cubes always lie on an edge you can get away with just using two neighbouring voxels - that should speed it up

There are papers available if you want to design more sophiticated filters but they get a bit mathematical. Search for "filter design" and I think the name "yagel" might be worth looking for. I'm away for a few days but I can send you a paper when I'm back.

Good luck with it - you might want to peek at my source code (espesially for the Sobel). Search for "computeNormals", or something. And just ask if you have any more questions.

As for the project, I haven't worked on it recently. I'm just busy organising a move to the Netherlands and preparing for my new job. But I hope to get back to it soon!

cursedbeast · Post by **cursedbeast** » Thu Nov 29, 2007 12:12 am

I've hacked around with the converter a little and got it running. Seems to work well enough but my converted objects aren't filled in (all hollow). Any idea what could be causing it?

Cheers
Chris

cece · Post by **cece** » Thu Nov 29, 2007 10:46 am

PolyVox wrote: Yes, they are voxelised from meshes. I basically take each triangle in the input mesh as repewatedly subdivide it until it is smaller than a voxel. Then I set the corresponding voxel to be 'on'. I made this approach up myself but it seems to work ok and is pretty fast (only a few seconds). Be aware it results in hollow volumes though, I haven't yet decided the best way to fill them.

i think that with the actual voxelization method every volume you obtain from a mesh is not filled inside.

if you are intersted:

cece wrote:regard the volume filling in voxelization phase i suggest you to see this:

http://citeseer.ist.psu.edu/cache/paper ... cation.pdf

See the "parity count" method. If you don't have non-watertight meshes it would be ok.

PolyVox · Post by **PolyVox** » Thu Nov 29, 2007 12:19 pm

cece is right, meshes always come out hollow. Basically the approach I used takes each triange in the mesh, recursively subdivides it until it is smaller then a voxel, and then makes the corresponding voxel solid. The result is the mesh is turned into a 'shell'of voxels which is hollow inside.

This does need fixing at some point, and there are a couple of ways to do it. One is like the paper which cece referenced - counting ray crossings - and this is probably the most robust way. An easier way would be to perform a 3D flood fill from a voxel inside the shell. So you make the shell and then you fill it. Of course, this only works if your shell has no holes and is closed.

It's worth bearing in mind that it could be beneficial to have a a different material for the shell and the inside. Then you can apply a fancy texture to the shell but have the inside made of stone or something. Also, having a hollow shell is bad for performance because a mesh will be extracted for both 'sides' of the shell.

Fianlly, it is also possible to create filled voxel models by rendering slices of the mesh using graphics hardware and using some stencil buffer tricks. I haven't looked at this yet but it could well be the proper long term solution. From within the game engine the user could move the mesh around and then click to convert it to voxels at that spot.

FrozenLogic · Post by **FrozenLogic** » Thu Nov 29, 2007 1:56 pm

Anyone could point me a way to get it installed? I mean, how to use cmake to create the build files.

Thanks.

milliams · Post by **milliams** » Thu Nov 29, 2007 3:09 pm

FrozenLogic wrote:Anyone could point me a way to get it installed? I mean, how to use cmake to create the build files.

Thanks.

There are simple instructions in the INSTALL.txt file provided. If you have any specific questions or problems with building, feel free to ask.

PolyVox · Post by **PolyVox** » Fri Nov 30, 2007 1:22 pm

Are you building on Windows or Linux? If you just want to test it then just grab the prebuilt windows version. Otherwise have a look at the INSTALL file a milliams says, but be aware that under Windows you need environment variables defined to locate Ogre. If you have the Ogre SDK then the installer should have set up $OGRE_HOME and it might just work. If you have source or CVS you need to point $OGRE_NEW to the source directory.

cursedbeast · Post by **cursedbeast** » Sat Dec 15, 2007 6:24 pm

Hello again! Quick question; Can you think of any obvious reasons the texture doesnt draw properly? I've rewritten the engine from scratch for my project using the polyvoxscene manager but when I render the scene the top layer of voxels (grass) just seem a detailess plane rather than grass. The other voxels draw fine, regardless of material.

Anything obvious come to mind?

Cheers

Chris

PolyVox · Post by **PolyVox** » Sat Dec 15, 2007 10:46 pm

So are you saying the grass texture has problems drawing, while the other materials work fine? Are they the same materials that I provided or have you made you're own? The only thing that springs to mind is that the profile is not supported for some reason and so the engine is dropping back to a different technique - are you setting the same profiles (vs_1_1 arbvp1, or what ever profiles you need) on all materials?

Other than that I think a screenshot would help me to see what might be going on.

Anyway, it's great to hear someone is playing around with this! However I must give you a warning - i'm drastically changing the way materials work at the moment. Earlier on I mentioned that I'd like to take advantage of DirectX 10 texture arrays, but I think I've found a way of doing the same thing on current generation hardware using texture atlases. This is only half implemented and so the code in subversion should not be used for the time being - the last usable revision is 451.

By the sound of it you've forked the code so this probably won't affect you. But if you are still updating then be aware that linear texture filtering may not work with the new texture atlas approach (i.e. you only get point filtering) so it doesn't look as nice. I may be able to fix this, or it may have to wait for DirectX 10. Also the mesh decimation stuff might get removed - it's not really as effective as I had hoped.

p.s. I noticed you've updated you details to say you live in Southampton! Not so far from me, although I moving away in a couple of weeks.

cursedbeast · Post by **cursedbeast** » Sun Dec 16, 2007 8:46 pm

heh small world! Shame your moving away! Could bribe info out of you with beer!

I'm not updating code, but calling it a fork seems a bit much, havent done anything to your code. I did hack around with the volume converter code to get it running for me, but then realised the whole hollow thing. Now I have my own generation program ( to generate a map from a png heightmap ).

Tis a wierd bug. It doesn't matter what material I use (changing material map), or what material number (changing gen script) I use the top layer always seems funky, even tho the sides don't.

I think it might be a resource loading problem as fiddling with the resource.cfg makes the other materials fail to render too.
Just noticed the following error;

Code: Select all

Error at line 1 of Wall.material: parent material: ColourMap2DOneLight not found for new material:WallMaterial

I think i need to fiddle my resource loading code, as despite specifying the material script doesnt seem to load it properly.

Some screen shots on the bug page here;
https://bugs.launchpad.net/colony/+bug/176747

Also if your interested the launchpad page ( https://launchpad.net/colony/ ) has some info about my project.

Thanks for the help!

PolyVox · Post by **PolyVox** » Mon Dec 17, 2007 12:45 am

Cool, it looks interesting. I'm quite impressed it's mostly work seeing as the code needs a lot of work. As for your problem, I don't exactly know but that error message could certainly be relevant. You see, the mesh generated from the code contains vertex positions and normals but no texture coordinates. These are generated in the vertex shader - if the vertex shader isn't found (as appears to be the case from that error) then there will be no texture coordinates.

Of course, it doesn't explain why some of the materials work and others don't. But I think you should focus on checking your paths and removing that error...

Entropai · Post by **Entropai** » Thu Apr 10, 2008 7:28 am

Hi,

Sorry to bump but what's the state of this? Are you still working on it?

PolyVox · Post by **PolyVox** » Thu Apr 10, 2008 7:45 pm

Entropai wrote:Hi,

Sorry to bump but what's the state of this? Are you still working on it?

Still active! Actually I stopped working on it between September and December because I was busy finishing my studies and moving abroad, but I've been properly back into it for the last three months.

The most significant advances is are:

1) The integration of rigid body physics using Bullet. You can dynamically modify the scene while objects bounce around.

2) The (mostly finished) separation from Ogre, allowing the library to be used in non-ogre projects. I'm still using Ogre for the showcase engine, though.

Actually I am expecting to release a new tech demo within a week

I just need to work on some issues getting the physics to update quicker when you change the environment.