Celestial Impact Forum Index
Author Message

<  General  ~  Technical details...

PolyVox
Posted: Tue Apr 01, 2008 9:13 pm Reply with quote
Joined: 01 Apr 2008 Posts: 2
Hi guys,

I tried your game a month or so a go and was very interested in your destructible environment technology since I'm working on something similar myself. I initially assumed it was based on a BSP addition/subtration technique but a recent post on GameDev.net implied it it was based on the marching cubes algorithm. I'm not sure what your aims with this project are (commercial, open source, etc) but are you able to talk about the technology?

So presumably you have a volumetric representation for the asteroid - what kind of resolution is this at? I've been working with 256^3 myself but don't know how much further I can push it. I'm also in tech demo stages so I'd be interested in how much difference there is between a tech demo and a real game (in terms of performance).

What kind of stucture are you using to represent the volume? I've gone for a brick based approach though a linear volume would be fine for the size I'm using. Or maybe it's an octree? And what has been the factor limiting the size of the volume?

Anyway, you can see my (GPL) work here: http://www.ogre3d.org/phpBB2/viewtopic.php?t=27394

It will be interesting to see how our approaches compare!
View user's profile Send private message
coorn
Posted: Fri Apr 04, 2008 10:53 pm Reply with quote
Developer Joined: 23 Jun 2007 Posts: 23 Location: Stockholm, Sweden
Hi, I'm glad your interested in our engine.

We don't really have a plan for the game except make it fun to play. The game will be free and if people start playing it we might release the game code so people can make mods, so I can talk about the technology as much as I want Smile

The main focus when I developed the world code was stability. It has to be super fast to render, fast to deform and fast to send over the Internet (since it is a online game). The world should also of course look as good as possible.

The maximum world size in voxels are 128^3. One voxel is about 0.8 meters in diameter (the player is about 1.8 meters high). This makes the maximum world height (radius from middle) about 50 meters, our biggest map is about 30 meters high.

All voxels are represented with 2 bytes, one for how solid it is and one for the material. The world is chopped up in 4^3 blocks and if a block is completely solid or empty we don't allocate it. Every block store voxels, triangles, collision data, etc.

All the vertexes are handled by a special module which consists of tones hash lists, pointers, garbage collectors etc. Very Happy All this mess to allow several world materials fading it to each other and avoid all kinds of cracks between blocks. All vertexes then get compiled down to one continues array and gets uploaded in chunks to the GPU memory. This minimize the amount of draw calls needed in rendering.

One of the most difficult parts is the PVS generation. Celestial Impact does an ok job here but there is often the case where over 50% of the world needs to be rendered and there is little you can do about it. This is one of the main reason we more then 128^3 not is necessary in our case because we first have to solve the PVS problem.

There is tones of stuff that could be improved in the CI world code. I would love to write a version 2.0 of it! Smile But since I'm the only programmer in the CI project I have to work on the rest of the game too.

Henning Tegen
View user's profile Send private message
PolyVox
Posted: Sat Apr 05, 2008 11:47 am Reply with quote
Joined: 01 Apr 2008 Posts: 2
coorn wrote:
Hi, I'm glad your interested in our engine.

We don't really have a plan for the game except make it fun to play. The game will be free and if people start playing it we might release the game code so people can make mods, so I can talk about the technology as much as I want Smile


Great, well mine is GPL but if it ever becaomes popular maybe I offere some kind of commercial option. It's too early to think about this yet though... So I guess we can discuss ideas Smile

coorn wrote:
All voxels are represented with 2 bytes, one for how solid it is and one for the material. The world is chopped up in 4^3 blocks and if a block is completely solid or empty we don't allocate it. Every block store voxels, triangles, collision data, etc.


Interesting, I use just 1 byte per voxel which represent the material. Different materials can have different strengths. But I guess the advantage of you approach is that it can take multiple shots to destroy a voxel. In my approach a voxel is either there or it's not, but you can decrease the remaining 'life' each time a voxel is shot (I don't see you doing this in game, but it should be possible).

Do you store the 'material' and the 'remaining strength' in the same volume? From a compression point of view it would seem advantagous to store them seperatly.

I also break my volumes down into blocks but with a difference - I use one block size for storing the volume and a different 'region' size for splitting the world into vertex and index buffers. So in memory my volume is stored as a series of 16^3 blocks. Or it can just be linear - I intend to provide different representations. But, regardless of how the volume is stored, my 'world' is broken into regions of 32^3. Each region corresponds to a vertex and index buffer which must be updated when any voxel in the region changes.

I don't know how useful my approach is yet, but it means that in the future I can store the volume as on Octree or something, while still breaking the world into regions.

coorn wrote:
All the vertexes are handled by a special module which consists of tones hash lists, pointers, garbage collectors etc. Very Happy All this mess to allow several world materials fading it to each other and avoid all kinds of cracks between blocks. All vertexes then get compiled down to one continues array and gets uploaded in chunks to the GPU memory. This minimize the amount of draw calls needed in rendering.


Agreed, maybe you could also look into using texture atlases ot texture arrays to reduce the number of draw calls? I have done this but actually I suffer from the traditional texture atlas bleeding artifacts. But I believe DirectX 10 texture arrays should solve this problem.

However, it brings up another interesting point - how do you generate you texture coordinates? I use triplaner texturing (check NVidia cascades demo presention for details) which works quite well but is noticable with regular textures such as bricks. I don't think you are doing the same but I may be mistaken as your textures are more natural. Or do you have some better approach?

coorn wrote:
One of the most difficult parts is the PVS generation. Celestial Impact does an ok job here but there is often the case where over 50% of the world needs to be rendered and there is little you can do about it. This is one of the main reason we more then 128^3 not is necessary in our case because we first have to solve the PVS problem.


I haven't really looked at this yet, but Ogre provides frustrum culling for each region. I'd quite like to implement Coherent Hierarchial Culling though. It should work for you too - there is an articale in GPU gems or see this paper:

http://www.cg.tuwien.ac.at/research/publications/2004/Bittner-2004-CHC/

coorn wrote:
There is tones of stuff that could be improved in the CI world code. I would love to write a version 2.0 of it! Smile But since I'm the only programmer in the CI project I have to work on the rest of the game too.


Yep, likewise. Too much to do and not enough time! One other thing I wanted to ask - your worlds don't look like marching cubes. Do you randomise the vertex positions in some way? Is it hard to do this without introducing cracks between blocks?

Anyway, it's good to share ideas, keep up the good work!
View user's profile Send private message

Display posts from previous:  

All times are GMT + 1 Hour
Page 1 of 1
Post new topic

Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum