The result isn't worse in my opinion.
For example you can even shoot tiny holes in the walls.

I think both approaches have their advantages.

it's basically just for better looks + easier use of polygons for physics...
the looks will even be adjustable per computer w/o interfering w/ the network synchronization. You can make explosions create holes in the background (better computer -> looks expand a few layers into the back, bad computer -> only use the front layer)
I know it's only used for 3d in that project, but the difference of 3d and 2d is just that 2d is looking along a single 3d axis.

and for the physics, I have not read much about it here, but from what I remember ppl want to use polygon physics engines and polygon landscapes.?

[edit] sorry about the confusion, the topic starter wanted to create voxelbased models for ingame objects, not landscape, since the landscape is basically already voxels (1xNxM voxelspace == NxM pixelspace ^^)

First of i'd like to apologize for not having replied for some time.

As ker said the basic idea behind this proposal is having better graphics.

> Sven2 said: Yes, and a "2D voxel engine" is a pixel-based engine. It's what we have right now.

Actually not. In an pixel based engine a screen-pixel has the same size as an object-pixel. In a voxel engine the voxels can be even smaller than a screen-pixel, thats where the graphics start to get better than in pixel-engines.
If the voxels are smaller than a pixel, like one fourth you could achieve a pretty easy antialiasing using ray casting (note: ray casting, not ray tracing. Ray casting has already been used in very old games, when PCs used to be much slower like 66 mhz). You cast like 4 jittered rays per screen-pixel resulting in an anti-aliased image of the current scene, given that a voxel is smaller than a pixel. Furthermore using a tree representation of the voxel-data, their position would be defined by the data-structure instead of coordinates. Although I haven't been into network programming yet, this might be benefitial for network synchronisation as less data has to be transfered.
Extending on the tree data representation you could have a fluid LoD enabling scalability in a much more effective way than pixel engines could achieve. Compared to polygon models you as well don't have to create seperate models for LoD. This can be automatically done by adjusting the tree-walking depth depending on zoom.

And then of course you got your rotatable 3D objects which are easier to animate than 2D images. One can even create convential polygon models and convert them into a voxel model. The advantage here is that you don't have to make several conversions compared to 2D where you have a small image of every animation step.

Another advantage I know of is that having your models actually solid you'd have a collision mask in itself by the voxel representation.

Of course this technology has a big disadvantage, one can't close ones eyes from it. As Sven2 said it lacks hardware acceleration. Though I think it's not that much of an issue as we wouldn't have that much data compared to a real 3D environment.

If something still not clear please ask me...

Hi Carli... actually I already started doing so...
It's not that I'd like to push everything into that direction though I would like to try and see how it will perform.
Although this is interesting I will be concentrating more on the "officially" taken approach as I neither want to have several different Open Clonk builds nor am I interested in splitting developers into a voxel- and a non-voxel-camp. I'd say the biggest advantage of open source is to work together. Not that everyone can take the source and make their own builds.

To cut a long story short (lange Rede, kurzer Sinn):
Together we code... divided we fall.