Here are 3 links to get an impression what voxel graphics are.
http://advsys.net/ken/voxlap.htm
http://voxels.blogspot.com/
A game inspired by Wolfenstein 3D... using a voxel engine.
http://voxelstein3d.sourceforge.net/
greetings
K-Duke
i think the gwx voxels are better in graphics quality: http://www.youtube.com/watch?v=0RhDQiHMfuY
>voxelstein has a very cheap voxel engine.
Their voxelmaps have also slightly higher resoulitions.
Can you name any concrete benefit from using a completely nonstandard approach?
benefit: zooming in won't create pixel-blocks... instead the precision of the converter can be adjusted for smoother graphics. physics can still be done in a synchronizable way by not adjusting them.
benefit2: smooth landscapes, easy texturing
disadvantage: sharp landscapes are not possible w/ the standard version of the engine.
I think all this stuff is more interesting for GWX.
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 ^^)
> it's basically just for better looks
I haven't seen any engine that would produce superior graphics yet. Polygon-based graphics technology is much more advanced.
> + easier use of polygons for physics...
So you're talking about physical interactions between objects? How will they become "easier"?
> 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.
Yes, and a "2D voxel engine" is a pixel-based engine. It's what we have right now. We want to move to polygon-based models for objects because the pixel-based approach (read: Have all animation phases pre-rendered) doesn't scale well and takes too much memory on high resolutions. We aren't moving to polygon-based landscape, as noone has written that approach (yet).
You want to make the situation worse instead by adding a new dimension of pixels that is actually almost never seen.
The most important thing would be still having the pixel landscape but rendering it with 3d polygons (smooth landscape, no pixel blocks)
and it would allow for polygon landscapes for physics which have been discussed somewhere, I just don't remember where
>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.?
So why don't we use polygon graphics as well?
it will allow for any level of smoothness for the landscape, no matter what the zoom. b/c right now even if you'd use 3d models for objects, the landscape will still be flat pixels w/ some kind of bumpmap/lightmap/whatever
>we would be using them... have you not taken a look at the link? the background data is still voxels/pixels, just the display and physics will be polygonal and updated when the voxel/pixels update.
Exactly, why not use polygons in the background data as well?
>it will allow for any level of smoothness for the landscape, no matter what the zoom
Right now we HAVE a voxel engine for the landscape. It is 2d, okay. So the voxels lack a third dimension and are therefore called pixels. But I cannot really see any difference when we add a third dimension (which you don't see anyway)
about synchronization: ok... the physics engine w/ polygons would introduce problems...
call it voxel, call it pixel, the point is that clonk will have blocky thingies there which can only look smoother by increasing the resolution (which might not be possible on all computers b/c there'll be good and bad computers in a game). w/ the voxel -> polygon converter you can create a smooth surface that is smooth at any zoom if the computer allows it (irregardless of all the other computers).
as said before, the third dimension is irrelevant, it's only a feature that could be abused for graphical effects. All I care about so far is the smooth landscape (which will look 3d since the polygons will actually be around voxels of 1 voxel depth (so basically a pixel that is extended into the back))
http://revar.livejournal.com/81627.html
Your proposal is basically: Leave the data structure of a two-dimensional pixel array as it is but have a second polygon based data representation of the landscape. The polygon based representation of the landscape is used for graphics and for the physics engine. It will be updated automatically on every change to the landscape. This is supposed to work with less effort and faster than using a modifiable polygon based landscape directly.
And this is were I loose you. Why do you think creating the polygons after each change on the landscape is A) less complicated to program and B) faster than directly modifying the polygons?
for A:
it can basically be used as a black box that gets pixel map input and returns the polygons which then can be drawn imediately. when the map changes, you tell that to the black box and your polygon output changes. I've even seen this technology be used for streaming infinite size maps.
for B: might not be faster, but it won't end up creating crazy polygons that are extremely thin and look more like errors than like map-parts. You will always generate your polygon world from a discrete world, so if you get messy stuff the generator is bad, but w/ a polygon world that is modified directly, anything is possible. I've not seen a good polygon-engine with on the fly modification so far. So this is just guess work and some experience w/ an experiment I did about a year ago (or maybe I'm just crappy @ polygon-math ;) )
what you think of is a marching cubes algorithm for 2D-Maps (called marching squares)
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...
>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.
But the modell-data that is finally saved and the engine has to import consists still of one "image" per animation step or doesn't it? I think a bone system is more efficient using polygon modells
>Another advantage I know of is that having your models actually solid you'd have a collision mask in itself by the voxel representation.
That is the only reason I see up to now - but it's not like that realistic collisions cannot be done in a polygon-based environment
The other advantage you mention, that the LoD can be scaled dynamically, does not weight more than the additional loading data (if it really is that way), I think
He does this by streching the voxels to fit the bone system.
> Sven2 said: They [voxels] generally have larger volumes of data to be pushed around.
This is true. Though one could circumvent this problem to some extend by using tree-data representation. One could even adjust it in a way that you only have walk the tree so much that one voxel has the size of one screen-pixel reducing the rendering data greatly for slow PCs. Though granted this would almost look like the convential 2D engine with a higher amount of data. Though really... do we still have to support a 300 mhz PC from 1998?
make an extra branch, implement your voxel landscape and when 3 GHz are fast enough we will use your landscape engine in the main branch.
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.
in this thread we discussed how to implement more than one landscape system: http://forum.openclonk.org/topic_show.pl?pid=2164#pid2164
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill