Hi,

I'm developing a game called "Forever War" which is based on your PolyVox technology.
The game uses the code from PolyVox in a modified form which supports smooth geometry -
voxels can have values from -128 to 127, and the surface is created where the interpolated value hits zero - just like in Nvidia's Cascades demo.
Actually, there's not too much left from the original PolyVox structure in the code because I've rewritten some parts of it for the sake of understanding.

I've set up a webpage with further information on the game here:
http://foreverwar.sourceforge.net/

A tech demo is available which shows the destructible environments and the basic game mechanics (running around, fighting against the first enemy type).

The next thing to implement will be paging for the voxel volume to support a bigger world.

If you are interested in the details of the current implementation, just ask.

Maybe you can even use some screenshots of the game to promote your technology, though the fact that all textures and models in the game were created by me (programmer art!) might disqualify it for this purpose

Thomas

Wow, that is really cool! I just had great fun jet-packing high above a map, raining down explosive barrels, and then taking pot shots to blow them up The only thing missing was the halflife 2 effect where they burn for a couple of seconds before exploding and sending nearby barrels flying across the map! I'm pretty sure you could make a whole game out of that concept

So, I am of course interested in the changes you made. From the looks of it (I only looked briefly) you took Thermite and PolyVox and cut out some of the stuff you didn't need. Then you added you own version of the marching cubes function which takes voxels between -128 and 127 and generates a smooth mesh using linear interpolation.

Now, in my version the voxel values represent the material found at any given point. You seem to have maintained the ability to have multiple materials - am I correct in thinking you now store two volumes? One holding the density and the other holding the material? If not, what approach did you use?

It seems you main rational for modifying PolyVox (apart from understanding it) was to be able to produce smooth geometry suitable for terrains. If this is you main aim, then actually there is an easier way. Basically you would just store the material volume (as in my approach), but you perform volume averaging on-the-fly as you generate the marching cubes mesh. That is, you can modify the getVoxel() function so that it computes an average value based on itself and its neighbours. Then you can run marching cubes more-or-less as normal.

Actually I did implement this approach, it only took a couple of hours to add it on to PolyVox. I didn't keep it in because it didn't look right to have my castle smoothed so much, but it might be just what you need for terrain. I might even still have the code in the latest version somewhere. If you are interested I will dig it out.

Are you planning to merge back into using my version of PolyVox/Thermite at some point, or are you planning to maintain your own version? I've put some effort into making PolyVox a separate stand-alone library (no longer dependant on Boost, Ogre, etc) so you might at least want to consider that part. It also now supports generating lower detail meshes which will be vary handy for scaling up the size of your world.

In fact, when did you create your version? I notice you are still using the texture atlas approach (I dropped that because of the artefacts when linear texture interpolation is enabled). I have also started adding shadow map support as shown here:



I wouldn't suggest you start to merge back in immediately, it's not really stable or extensible enough for that yet (which may be part of the reason you made a branch in the first place). But you might want to keep it in mind for when I have a clean separation between PolyVox, Thermite, and the game that uses them. This will probably improve over the next few months.

Anyway, once again, excellent work! I really look forward to seeing where this project goes And I'll be happy to help out where I can.

I originally planned to implement the burning effect for the explosive barrels, but then postponed it because other things were really more important

You are right, in my version for every voxel the density and the texture number are stored separately. Only storing the material volume and then averaging the voxels sounds interesting, but this will only allow for smooth geometry - I'd prefer a mixture between smooth parts and parts with hard edges for things like buildings or hallways, which are possible with my approach by using values like 1 for ground and -128 for air so that the surface is very close to one voxel. This way, the edges are almost hard, but I'll need to do something about the normal vectors - they make it still look like if it's smooth.

Merging back to using your version of PolyVox would be tempting because of all the cool features you're implementing, but having a separate version has also some benefits:
- as said above, the way I store the voxel data works really well for me (but it looks like I could use two volumes for the data and write a custom surface extractor to do that in PolyVox, is this correct?)
- I can implement new features quickly. For example, currently I'm working on paging, so that the volume acts as a window into a larger world which moves with the player. If that would have to be implemented in PolyVox, it would have to be as flexible as possible, while my implementation just has to be good enough for my game

But using PolyVox would be good because ...
- you are working on it and improving it
- it would help PolyVox because it's used in a real application

I'm currently not sure if I should merge back to use it. But for example the paging feature is a must-have for my game.

I started my project around March this year, so that must have been the time I started to create my version.

The texture atlas works for me now almost without artifacts (at least in OpenGL, in DirectX there are still strong seams visible) due to the way it is generated. Every texture in the atlas is only 480x480 in size and centered in a 512x512 area. The unused border is filled with texels colored like the border texels of the 480x480 image (like in the clamp texture address mode). Only if you look closely you can still see small seams in the texturing. At least with my graphics card - did you notice any seams?

The bigger problem with the texturing is the blending between the textures. One triangle can have up to 3 different textures, so I now have 9 texture accesses in my shader without any normal map or something similar! And if you use multiple alpha blended triangles to simulate texture blending, there has to be a pass with a ground color first because the result is always translucent. Or is there a better way?

Anyway, thanks for your support and work on PolyVox and Thermite

True, but you could always check the value of the material and use that to decide whether or not to average it with its neighbours. So it you got a terrain voxel you would average it, if it is a brick voxel you wouldn't. In fact, I should have thought about that for my castle - maybe I'll go back and add it. I can imagine there could be discontinuities where smoothed voxels meet non-smoothed ones though.



Yes, you could just have two volumes and have your own marching cubes implementation. However, rather storing two seperate volumes, you could take advantage of the fact that the BlockVolume class is templatized on the VoxelType. So you could just create a custom struct containing your material, density, and whatever other parameters you want and use it directly with the existing BlockVolume. Of course, you would still need your custom marching cubes implementation. This probably wouldn't get added to PolyVox, but you can just add it at the 'application' level.

So what would be the advantage of just having one volume? Firstly it's probably more elegant. Secondly, your material and density for any given voxel will sit next to each other in memory, whereas they are currently being pulled from very different areas of memory. So it would be better for the cache.

A disadvantage could be that volume compression could be a bit more tricky. This isn't really implemented yet, but I'm just thinking to the future


I would say that for the time being you shouldn't merge back. What you have works for you and you probably want to concentrate on the game. However, you might want to consider merging in the future (maybe in a few months) and try not to duplicate features. I will try to give you some idea where I'm heading in the next few months:

• I'm cleaning up interfaces and ensuring a clean split between the PolyVox library, the Thermite game engine, and the game. I guess this will be important for you.
• I'm experimenting with porting to Qt. This will reduce the number of dependencies and the complexity of the build process. More importantly, it will provide a flexible GUI which can be customised by style sheets.
• I will be writing an in-game editor, hopefully built on the new Qt framework.
• I will be polishing the shadowing support and large volume support. Both of these are currently in the prototype stage.

Ok, this had occurred to me but I wasn't prioritising it. As mentioned above I will be working on large volume support, and paging could be an extension of that.

Currently my volumes are 256x256x256 - I assume yours are the same? Actually I was impressed by how big your volumes seemed as I believe you could already have a death-match style game in there. I hope to push the volume size up to 1024x1024x1024 but of course there are no guarantees yet



I did notice seams, but I was probably looking more carefully than your average gamer



Argh, the texturing has been a pain in the ****. I will give you a little history:

• Initially I was creating a separate mesh for each material in each block. I also had to deal with the edges between adjacent materials. I *think* that I was creating three meshes for each edge (one for each of the materials which could belong there) and then doing some blending magic. This all worked but I wanted to lower the batch count.
• I then moved to the texture atlas approach. Then, for each block, I would have two meshes. The first mesh contained all the triangles which used exactly one material (and so didn't requre any blending). The second mesh contained the triangles along the material boundaries, and I think it actually contained each triangle three times. These two meshes were referred to as something like 'SinglePatchRenderable' and 'MultiPatchRenderable'.
• Finally, I have ditched texture atlases and now pass the textures in different texture units. I now use exactly one mesh per block which handles both single and multi material triangles. PolyVox generates a slightly simpler structure, and the details of the rendering are now the concern of Thermite. It is possible that Thermite receives a triangle from PolyVox which contains three different materials - in this case Thermite discards the triangle and replaces it with three separate triangles.

There will doubtless be more changes. Firstly I want texture arrays. Secondly, I can see that I some cases I really do want a separate mesh for a material - for example if that material is semi-transparent (you could have ice in your game). Transparent meshes need to be rendered separately.



No problem, I'm really glad someone is using it. Back to one of your original points, would you mind if I added a 'Projects using Thermite/PolyVox' page and included your screenshots in there? It would then be clear what was yours and what was mine. Also, when do you intend to start promoting your work more publicly (Ogre Forums, GameDev, etc)?

Wow, thanks for the detailed reply!


Yes, and then you'd have to work around these discontinuities somehow ...
But making a special case for certain materials will probably work to fix the normals of hard surfaces when using my method.


The world was actually smaller - in the demo I used a 192x192x192 volume, divided into 16x16x16 blocks.
I think the smoothing of the geometry and the resolution of the textures are important to make the world seem bigger. You can then use less voxels for the same space. It could also be the kind of the geometry represented by the volume - the terrain doesn't need as much detail as for example your castle.


Okay, so it seems like there is no best-for-every-purpose way for texturing the geometry
On my wish list for texturing are detail textures and some 3d color variation texture like in Nvidia's Cascades demo, but this will result in even more texture accesses. Currently, I'm rendering all voxel-generated geometry with the same shader, which does 9 texture accesses, as already mentioned. It can use dynamic branching to prevent the unneccessary ones, but I'm unsure if that really helps as I don't have benchmarking functionality in the game. What were your experiences with your second texturing approach - do you think it helps to split the triangles into "no blending" / "need blending" groups?


Yes, that would be ok.


In the current state the game is more like a sandbox - you can edit the world, throw objects into it and see what happens.
Before I promote it I'd like to have a bit of the real gameplay in it.
I currently intend to create a gameplay inspired by roguelikes (for example NetHack) mixed with FPS elements, but I have no idea how well this rather exotic idea will work out.
If it's not fun, there's still the possibility to try a multiplayer shooter, which will surely be great fun if it is technically doable.

No problem. But actually I will be away until Sunday now so my replies will slow down. And soon after I'm off to the US for a couple of weeks. Actually I expect to make very little progress in September but don't worry, the project is not abandoned Just scheduled down-time.



Well that's good to know - if I can push it up to 1024x1024x1024 then I hope it can create some pretty impressive environments! But I know now that even a small environment could make an interesting game.



Well, I do think that my current approach is simpler though I don't know really how the performance compares. I have exactly one mesh per region which makes the physics easier, and also the Marching Cubes code is more readable. I was doing some weird stuff before to split it up during the marching cubes execution. If you do want to separate the different materials into different meshes then I think it is actually easier to do this as a post-processing step on the mesh . Then you can leave most of the mesh as one, and separate out just a particular transparent material, for example.

Also, even if I got the perfect system now I'm sure it will change with new features. Shadow mapping caused some complications (using up textures units) and so did implementing multi-resolution mesh extraction. I'm sure displacement maps, detail maps, and transparent surfaces will also require further thought. So I'd rather get these features in before aiming for the 'perfect' system. But, in general, I believe the system is improving with each change.