Since there seem to pop up so many new voxel rendering engines recently, I thought about starting a new thread to collect information about them and how they work. (Some were mentioned already in threads here and elsewhere)
List of voxel engines Chronological order
Atomontage : The most recent I found today is the Atomontage voxel rendering engine. They actually claim to render multi million voxel scenes in real-time (10 fps ? 100 fps ?). Since they say they compress one voxel to less than 1 bit, I'd guess its a pointerless octree kind of datastructure. In their tech-info they write that they render about 7M surface voxels in the scene, which makes me guess it might be a kind of point-rendering engine rather than a raytracer. (GPU) 2009 http://atomontage.com/?id=home
Unlimited Detail: Some time ago, I came across an article about rendering tons of voxelized charactes. Actually, they seem to use a kind of point-rendering approach. Unfortunately no demo or detailed tech infos. (GPU), 2008 http://www.tkarena.com/Articles/tabid/59/ctl/ArticleView/mid/382/ArticleID/38/PageID/170/Default.aspx
Zelex : SVO Raycasting + Streaming (GPU, CUDA), 2008 http://ompf.org/forum/viewtopic.php?f=3&t=904
Jules Urbach seems to work on a voxel engine for ATI. (GPU), 2008 The screenshots so far dont show any clear evidence for voxel technology however.. http://ompf.org/forum/viewtopic.php?f=6&t=882&start=150 http://www.otoy.com/site/about_otoy.pdf
IJs: Voxel Raycasting (GPU, CUDA & Rapidmind), 2008 http://www.jonof.id.au/forum/index.php?topic=1433.0 http://ijs.mtasa.com/?page=gfx
Mars 5k Demo: Voxel terrain (CPU), 1994 http://ftp.lanet.lv/ftp/mirror/x2ftp/msdos/programming/misc/mars.lzh
The beginning: Commanche, Voxel Terrain (CPU), 1992 http://en.wikipedia.org/wiki/Comanche_series
Common Technologies
1.) Heightmap based Voxel-Terrain. http://www.flipcode.com/archives/Realtime_Voxel_Landscape_Engines-Part_1_Introduction.shtml
2.) Voxlap Technology / Raycasting RLE volume data in planes orthogonal to the horizontal plane. http://www.jonof.id.au/forum/index.php?topic=30 https://eprints.kfupm.edu.sa/22135/1/22135.pdf
3.) Splatting / Rendering voxels as sprites http://www-graphics.stanford.edu/software/qsplat/ http://www.graphics.rwth-aachen.de/uploads/media/octree.pdf
7.) Rendering Voxels as Polygons http://en.wikipedia.org/wiki/Marching_cubes
if somebody knows further interesting sources, I'm eager to hear/see.
Changelog 18.Feb.09: I added Voxlap and other engines now as well. I first thought to make a list of the most recent engines which might be new to some of you, so its more interesting to read - but I think esuvs is right, a complete list is the best. 19.Feb.09: Added further game engines using voxels from http://en.wikipedia.org/wiki/Voxel . And here a list of more games using voxels: http://www.mobygames.com/game-group/games-with-voxel-graphics/offset,0/so,1d/ 20.Feb.09: Added references to the most common technologies. 14.Mar.09: Added another reference to a diploma thesis about SVO (3/2009) + Timothy Farrar (SVO raycasting)
Edited by Spacerat at
ConsistentCallsign at
Re: Voxel Engines
QSplat
Edited by TheodoreRobertCowell at
esuvs at
I'd like to throw in mine, of course:
http://www.thermite3d.org
It's a hybrid polygon/voxel engine in which the world is stored as a volume but converted to polygons for rendering. Also features rigid body physics.
0xC0DE at
esuvs said at
I'd like to throw in mine, of course:
http://www.thermite3d.org
It's a hybrid polygon/voxel engine in which the world is stored as a volume but converted to polygons for rendering. Also features rigid body physics.
yes, I still think your engine is one of the best (ast least from a visual point, it just looks awesome).
esuvs at
Hugo Smits said at
yes, I still think your engine is one of the best (ast least from a visual point, it just looks awesome).
Thanks, but I hope to make it much prettier. I'm working on tools/content pipeline issues at the moment, but in a couple of months I hope to give it a graphical overhaul. I've already go basic dynamic shadows in there, and want to add bump mapping, refraction, HDR, etc. Well, I'll post here when it's done of course ;)
ConsistentCallsign at
Hugo Smits said at
I still think your engine is one of the best
i still think the engine is one of the worst
*EDIT* and the slow piece of shit engine just crashed my computer >:(
You just dont combine vertices with voxels. It's fps murder, kinda like marrying a cat with a mouse.
:D
Edited by TheodoreRobertCowell at
hark at
It wouldn't be FPS murder if you had a modern graphics card. There's a reason why most, if not all, current voxel engines render using polygons. It's to take advantage of hardware acceleration. Just wait until general-purpose graphics processors gain prominence and maybe then we'll see voxel engines that don't rely on conversion to polygons for hardware acceleration.
esuvs at
Well there are certainly some promising raycasting/splatting based renderers in that list. I think that http://www.icare3d.org/blog_techno/gpu/gigavoxels.html, http://atomontage.com/?id=home, and http://www.tkarena.com/Articles/tabid/59/ctl/ArticleView/mid/382/ArticleID/38/PageID/170/Default.aspx look the most promising. Certainly the future will be interesting...
Also, how com Voxlap was missed of the list?!
0xC0DE at
an older engine, which looks alot like voxlap :
http://www.momorprods.com/tracy/index.htm
also, Westwood Studios' Command & Conquer: Tiberian Sun and Command & Conquer: Red Alert 2 use voxels to render most vehicles.
Edited by Hugo Smits at
ConsistentCallsign at
hark said at
It wouldn't be FPS murder if you had a modern graphics card.
Wrong. It will still be fps murder. GPU-acceleration does not justify making slow and sloppy engines.
Yeah, let's render each voxel as a high-poly mesh with thousands of triangles. We'll just use big power-hungry poly-pushing monsters and the fps murder will go unnoticed :o :o :o
Want better visual quality? Then increase the voxel grid resolution.
Edited by TheodoreRobertCowell at
Spacerat at
For rendering voxels as polygons, I recently figured out something interesting : Rendering one 6-sided voxel, or more precise one rle-element, as a cuboid in cuda is about as fast as rendering one triangle with unshared vertices in GL. In my case (8800Gts), the max. triangle performance is about 133M/s for triangles with independent vertices, while the voxel performance is about 117M rle elements/second.
If a voxel grid is visualized by a polygon mesh, its different. One voxel maps to about one quad with shared vertices. In case of shared vertices, my cards max. performance is 280M tris/s = 140M quads/s. This means for performance reasons its no big benefit anymore to convert voxels into polygons - for mesh smoothing, antialiasing and polygon reduction it might be a help though.
Sebastian at
Hi spacerat
Im searching for an algorithm that subdivides a voxel grid into simple OpenGL Primitves. Which algorithms do you use for this?
Rgrds
Sebastian
0xC0DE at
TheodoreRobertCowell said at
hark said at
It wouldn't be FPS murder if you had a modern graphics card.
Wrong. It will still be fps murder. GPU-acceleration does not justify making slow and sloppy engines.
Yeah, let's render each voxel as a high-poly mesh with thousands of triangles. We'll just use big power-hungry poly-pushing monsters and the fps murder will go unnoticed :o :o :o
Want better visual quality? Then increase the voxel grid resolution.
[sarcasme]yes, because increasing the voxel grid resolution doens't affect FPS in a negative way at all. [/sarcasme]
And you still need to buy new hardware (alot of RAM).
ConsistentCallsign at
Hugo Smits said at
[sarcasme]yes, because increasing the voxel grid resolution doens't affect FPS in a negative way at all. [/sarcasme]
True, but you see, some fps murders are justified and are necessary 8) High-res next-next gen software-driven voxel games are the future 8)
Hugo Smits said at
And you still need to buy new hardware (alot of RAM).
RAM is cheap these days 8) Modern GPUs, however, are becoming increasingly more expensive due to the waste of silicon (and more expensive bus plumbing) 8)
Spacerat at
Sebastian said at
Im searching for an algorithm that subdivides a voxel grid into simple OpenGL Primitves. Which algorithms do you use for this?
Hi Sebastian,
in HVox I used a very simple way where each voxel is treated as a 6-sided cube. I decided to do this as its difficult to connect LOD boundaries otherwise (with one of the algorithms below).
The most common way to convert voxels into polygons: Marching Cubes http://en.wikipedia.org/wiki/Marching_cubes A better algorithm is described in this paper: Dual Contouring of Hermite Data www.frankpetterson.com/publications/dualcontour/dualcontour.pdf Or this one (with LOD): Interactive View-Dependent Rendering Of Large Isosurfaces https://computing.llnl.gov/vis/images/pdf/vis02_gregorski_final.pdf
regards, Sven
Edited by Spacerat at
esuvs at
Whoops, looks like I stirred up a hornets nest ;)
That has become an excellent and comprehensive list though!
husky at
Re: List of all Voxel Engines
Hello Spacerat,
I was glad to find my engine in your list - thanks for mentioning it! :)
Blah blah...terms. You still have to cast a ray regardless.
There's a HUGE difference between casting and tracing :o
casting = obsolete tracing = teh future
:o
Jinroh at
Yes, the results are different, but they both involve casting rays. I mean they both involve ray-surface intersection.
I see you changed your opinion that voxels are the future. ;)
BTW Is that you dog? Cute.
Edited by Jinroh at
ConsistentCallsign at
Jinroh said at
I see you changed your opinion that voxels are the future. ;)
LOL!! No.. :) When I type raytracing, I am referring to (3D) raster raytracing 8) RRT FTW! :D
I find it extremely offensive that you call me a polygonist >:( Want me to call you Hitler? It's the same thing :P Just kidding :P
Edited by ConsistentCallsign at
hansk at
Atomontage seems most interesting in that list. I think compression is a big problem with voxels, they just take so much space. If they really have it down to 1 bit per voxel then I'm really impressed.
Jinroh said at
Blah blah...terms.
Just for the record, IAWTP :P
Spacerat at
Thats true - memory is the no1 problem with voxels. I think 1 bit per voxel as position data is a good start - next important is to compress normal+color data, perhaps using lossy compression algorithms like jpg or wavelet. As recent GPUs have a lot of Flops, such a compression is maybe not such a big speed impact.
toasty at
hi!
i am also working on a voxel-based volume renderer. spacerat, you will already know me from the ompf forums under the name 'iridis' (i have made much progress since my first posts there!).
i use a regular grid of octrees, and at each octree leaf there is a regular grid of voxels.
current implementation is on cuda, but i would like to try other options since framerate is not spectacular (512x512, 10hz-30hz).
this is not directly for application to games, it is more for general visualisation. it forms part of a larger project to create an entirely volumetric 3D graphics editing suite. the editor's design is focused on a hierarchy of non-discrete subvolumes defined by user-editable expressions. this is far removed from the '3D painting' process familiar to users of the voxlap editor, but allows the same effects (and much better ones) to be achieved.
no code has yet been written for this editor, as i am working on a tool for baking illumination onto voxels. the renderer does not currently trace lightpaths.
1 bit per voxel sounds like an impressive rate, but i really wonder how that can be put into perspective. the encoding scheme i use results in 6 bits per voxel in a leaf (each leaf contains 4x4x4=64 voxels). but there is also 8 bits overhead for each octree node, to indicate empty regions. colour quality is slightly better than S3TC (but scheme is much different!), alpha quality is 'perfect' 1-bit per voxel.
toasty at
a conversion from a quake 2 level, no texturing. the noise is due to monte carlo sampling of illumination.
http://i39.tinypic.com/dzgeg2.jpg
only the first bounce is computed, so there are no colour bleeding effects.
http://i43.tinypic.com/aetts1.png
the rays for illumination are intersected with the original bsp geometry, not the voxel geometry. this means that lightsources must be constructed from polygons. i will be redesigning this to directly use voxels as light emitters.
0xC0DE at
haha.. that looks really funky! I like it :D
what's the current FPS ?
toasty at
in these shots, the renderer was running at about 15hz. that is way too slow in my opinion.
i will try a gpu hybrid rastering+casting approach, then an entirely cpu-based one.
my machine is an intel pentium dual-core, 1.8 ghz, 3.25 gig of ram, nvidia geforce 8600 gt
my renderer utilises both cores. one thread is for cuda and rendering (cuda contexts cannot be shared across threads), and the other is for decompressing voxel data as it is needed. video memory usage is made constant by use of a voxel data pool.
straaljager at
wow, that looks really good! I especially like the noisy look of it. Is the lighting being computed on the fly? Any chance for a demo?
toasty at
straaljager said at
I especially like the noisy look of it.
i think the noise is acting as a substitute for texturing here! the only colour specified is a solid tone for each bsp leaf. if texturing were used, the noise would seriously deteriorate quality. and quake 2 textures are bad enough already....
the noise can be reduced by extra sampling (see below as to why this is prohibitive) or postfiltering. i think filtering would work well, but needs a distinct separation between colour and incident illumination i.e. two sets of voxels. this separation is already part of the design, but not the current implementation.
straaljager said at
Is the lighting being computed on the fly?
the lighting is pre-computed with a lengthy distributed ray tracing process. i tried to reduce this precomputation time by increasing the number of samples near directions where light-emitting leaves are known to be. but the leaves of a quake 2 bsp are too big to make this a real improvement.
this adaptive sampling will work much better for pure volume tracing, as there is a good trick for indicating regions that require additional samples.
straaljager said at
Any chance for a demo?
i would love to release a demo, but this is a very early stage in development (still researching) and as such the renderer and conversion tool are not well-written.
the most promising developments, in my opinion, are the atomontage engine and john olick's (id software) svo. this is going only by what has been presented. in terms of released software, spacerat's demo has been my favourite. partly because it was actually released!
LordBringSomeLag at
http://www.minecraft.net/
A sandbox building game. The map is procedurally generated and it supports multiplayer. Seems like it has some potential.
However, I have only one thought: first person voxel roguelike. ( ;))
ConsistentCallsign at
Kodu Game Lab LOL!!11 :D
It has an "interactive terrain editor" that looks like a voxel terrain rendered with polys.
Yeah, it's definitely voxels, alright: http://www.youtube.com/watch?v=CifX96oZWMs Which means that it uses a terrain voxel engine! :o :P
Edited by ConsistentCallsign at
esuvs at
It looks interesting, but hard to say it's voxels. I don't see any overhangs so it could just be a heightmap. There a video here of the world being edited:
http://www.youtube.com/watch?v=R-lM6Gf7pC4
Interesting stuff none the less...
psychorosti at
Some newer research from NVIDIA Developers with Source Code and Video on Sparse Voxel-Octrees and Raymarching with CUDA.