Quote:When I said how they work in terms of games I was more implying how do they fit in with the fact that GPUs work on polygons etc.

There are several techniques for rendering volumes. In medical imaging we often use the "slice" technique. Basically you create a 3d texture on the video card, and then you render slices (quads) at regular intervals, setting the texture coordinates accordingly. You can then do some very nice visualizations using clipping planes to see cross sections of the volume or adjust the alpha values to remove voxels of certain tissue density (for example, set the alpha of any voxel with the denisity of skin to 0.0 and visualize only the hard tissue).

Quote:I guess this is because of the processing required and the lack of hardware support?

Pretty much. Volume rendering can produce a lot of overdraw, which means your video card needs to have a very high fill rate to render a full volume at interactive frame rates. Most video cards have pretty poor fill rate performance due to the limited memory bandwidth (though this is improving). Even if the video card supports 3d textures, the limit will often be 512^3 or 256^3 or smaller. We regularly have to deal with large CT scans that can be 1GB+. This will not obviously not fit in video memory (although this is also changing rapidly). A common solution is to break up the volume into smaller volumes, and build the full volume by rendering the small chunks in multiple passes ("bricking" technique).

Quote:I'm assuming you mean ram here? Although if a voxel is treated as binary, how is colour applied - surely each voxel can't be assigned a 32-bit colour... The memory demands would make it unusable.

You can use hardware color tables to map voxel values to color values. You can also use pixel shaders to create more complex transfer functions.

Quote:Original post by NewBreed

Quote:
although ken's work is rather impressive, and if combined with some form of hardware accelaration

He certainly seems to know what he's doing! The optimisations in his source code are extreme!

Check out the publications on Sven's page - I think they have a lot in common with what Ken does. I'm not really able to tell you much about this though...

Quote:Original post by NewBreed

Quote:
you may encounter confusion with other games which claim to use voxels

Yes, I've already seen the marketing for those games, didn't know that it was just hype though.

Well that's my opineon, rather than solid fact ;-) But they don't use volumes, so it seems a bit cheeky to call it a voxel engine.

Quote:Original post by NewBreed

Quote:
Run-Length Encoding approaches can be used to reduce the memory requirements.

I'm assuming you mean ram here? Although if a voxel is treated as binary, how is colour applied - surely each voxel can't be assigned a 32-bit colour... The memory demands would make it unusable.

Good question - actually I guess how you do it is up to you. In my case I allow one byte per voxel and this is used as a lookup into a material table (including textures, etc). So this gives you 256 different materials in your world. But the concept of texture mapping doesn't really apply in the same way (you need to think how voxels would get thier texture coordinates?) so you lose a lot of flexibility compared to polygon engines.

Quote:Original post by NewBreed

Quote:
I'm currently trying to seperate my voxel code into a library which can be used by other applications, so if you give me a few weeks you might be able to make use of that (it will probably be GPL).

I look forward to it and will keep a close eye on the project page. ;)

Great, but it will be a while before I post again as I want to add some physics before showing it off. But I could always send you a private message when the seperation is done.

Ken Silvermans code was written when he was 16, as was his 3d engine (or before that age).

3DRealms found his engine, and bought it/employed him - thats when Duke3D was made (the Build engine, ie Kenneth's Build Engine).

Duke3D was voxeless, even though the engine allowed it (aswell as heaps of other stuff)

They they made Shadow Warrior, and Monolith made Blood. Both these games used voxels.

when i was in the team for duke3d v2 (eduke, the project with matt saettler who was the programmer on blood or shadow warrior - or both, i forgot, check his website) they re-added voxels to the duke3d game.

Also, Ken's code allows for a conversion that generates from a multi-sided sprite into a voxel model (takes slices out of a cube from different angles).

His code is lots of fun to play with - however you (atleast use to) need the watcom compiler and usually used the dos4gw expander. I think there is a free watcom c around somewhere now, and ken may still have the code on his website for the entire build engine.


As for delta force - i think the voxels were only used for the grass (strands of grass) and maybe for some of the towers in the air, and when a weapon was on the ground, the rest was polys.

As for a voxel, it doesnt have to be a cube
http://members.optushome.com.au/jlferry/download/
its any volume. its like when you do FEA, its a voxel, an infinetly small volume, but it can be any shape - cubes and balls are the easiest to render and represent, and in most cases a cube or pyramid is the fastest, but you COULD render thousands of tiny volks wagon beetles, where each car represents a point in space.


http folder

the ball in that image was around 1000000 voxels or something. - i forgot.
basically a sphere with a diameter of about 128 pixels - could have been bigger, i forgot, maybe 256. the data was stored in a 3d link list (oh, the build engine is a great example of a 2d linked list, including the voxels).
In that screenshot, its running at around 30 (top left - and i forgot what the third line/scale was for - it was timing something) - 6 colourd lights (non directional) in textured mode. was on a geforce 2 on a 1.6ghz amd i think.

If you can get it to work I'm rather happy - I'm sitting at work and it won't run :)
If you can run it, the right hand side is to turn on lights and change colours of it etc, the 4 small square icons are for the rendering mode, spherical, cubic, textured cubic or point voxels.
It's about 3 computers and 6 hard drives ago (2002), so i MIGHT be able to find the source code, but I'm not willing to.

//edit - used ubb code instead of html

Quote:Original post by NewBreed

Quote:
when i was in the team for duke3d v2

You helped make duke3d? :O I remember playing that around my mates house for hours and hours! Dukes' voice clips were fantastic. :D Those trip bombs were brill. ;)

I would guess that Duke3D v2 was an unofficial update, the Duke3D sourcecode was released under the GNU GPL in 2003.