Voxel Engine

if you really do cross platform development, then Linux porting should be easy. I may help you in that.
Btw it looks real nice!!! I really like that doesn't try to look like minecraft. Is there a reason why the rocks in the foreground look pixelated?

Looks really nice! Are you using the same approach as in Silvermans Voxlap?
Is the ray casting done on CPU or through shaders/cuda etc?
Also are you approximating the AO with a volume texture?
I look forward to seeing more from you about this project,
I abandoned my shader-raycaster after accomplishing everything i wanted in terms of rendering, because i found that my technique was too slow for mainstrem hardware.

Keep up the good work!

Just saw the polygon-based voxel raster bit! Incredible! What is your polygon count and your point count, respectively? (I asdume you have some particle based voxeks in there, too!) :-)

@Yours3!f -
Yeah Linux should be very easy - I currently compile on a Mac with g++. The rocks in the foreground look pixelated, but they are actually "voxelated" - that is, you are just seeing each voxel that the rocks are composed of.

@SuperVGA-

It does look a lot like Silvermans Voxlap but is completely different in code (he uses very advanced software rasterization, I use relatively primitive hardware/polygon-based rendering techniques). I too did try to do raycasting, but found it to be too slow (at least without crazy optimization). The polygon count is very high, I dont have an exact figure on hand (I will determine it soon), but it is able to pump out a lot of polygons because they are (kind of) sorted front to back (on a per-chunk basis), and very little pixel/vertex shader code on each one.

AO (and all lighting) is semi-static (can be updated every couple minutes though, for daylight changes), and baked into the voxel/polygon color, another reason for the speed

A couple questions:

So how much memory would all this procedural generation take up in a save game or etc.? It sounds like a lot more info than minecraft, and I'm imagining savegames possibly getting rather bloated.

Also, any plans on texturing?

@ "Frentic Pony" ( Nice name :] ) -

So here is how it works:

Almost all data is generated procedurally, but there are special entities where the voxels are explicitly specified (mostly things like in-game items such as weapons, armor, food, etc). Overall, the minimum footprint for the game will be pretty small (everything together is currently less than 50k in size!! - but will probably be quite bigger in the future).

Saved game states will not take up a huge amount of data - almost everything is generated from much smaller data (i.e. a building only stores location of the walls, height of ceilings, materials used, etc). Damage/digging/modification is stored on a per-instance basis though. Most over-arching actions in the game are stored at a higher level (for example, one political faction over-taking another). But this stuff is a ways off still, obviously

So what takes up the most space? Caching. The player can allocate how much disk space - and even which disk - they want to use to cache the data. This will store every block (locations are implicit though) of any procedurally generated data (at least the CPU-intensive part of it). On the plus side, cached chunks load almost instantly.

As far as texturing goes, the every voxel will have material properties (how much light is reflected, ambient lighting, etc). Each voxel forms its own 3D texture - if I wanted to, I could vary each of the voxels in the image with a bit of perlin noise to give them a more "textured" look. There will be no 2D (or surface) texturing) - this is good because I do not run into many problems with UV coordinates - rather all textures are based on the object space of the voxel.