 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
 GameDev.Net Discussion Forums  Image of the Day Experimental Voxel EngineSend Topic To a Friend | View Forum FAQ | Track this topic | View Forum |
 Last Image Next Image  |
| Experimental Voxel Engine |
|
 |
  spacerat Member since: 10/26/2006 From: Yokohama, Japan |
|||
|
|
||||
Here a first demo of my experimental voxel engine. Visualized are about 10000^3 voxels by repeatedly rendering an example scene ( 1024x1024x1024 ). The data is run-length encoded (RLE) and at the moment only 3DOF are supported. The rendering is done simply from front to back by using "mipmaps" of the volume data - so there is much left for speed optimizations. You can download the demo here Update (16.3.2009): The new version's IOTD is here: Cuda Voxel Engine cheers, Sven --- http://www.p0werup.de http://voxels.blogspot.com/ [Edited by - spacerat on March 15, 2009 11:24:00 PM] |
||||
|
||||
 |
Ravuya Moderator - GDNet Lounge Member since: 2/13/2001 From: Okotoks, Canada |
|||
Posted - 9/27/2007 9:58:17 PM |
||||
| That is one freaky looking tree. I like it. ravuya: [Website][Not Your Journal] |
||||
|
||||
|
mightypigeon Member since: 4/26/2007 From: Melbourne, Australia |
|||
Posted - 9/27/2007 11:58:22 PM |
||||
| I had a play around with it. Quite impressive. |
||||
|
||||
|
PolyVox Member since: 11/24/2002 From: London, United Kingdom |
|||
|
Posted - 9/28/2007 6:25:42 AM |
||||
| Interesting, can you also do destructible scenery like in Ken Silvermans Voxlap? And I assume you're approach is based on raycasting? All CPU? I'm working on a voxel engine myself, but mine is based on Marching Cubes and currently I'm only on 256^3. I'm hoping to push it to 1024^3 though. |
||||
|
||||
|
phantomus Member since: 3/10/2004 From: Houten, Netherlands |
|||
|
Posted - 9/28/2007 8:12:16 AM |
||||
| What are you using the MIPmaps for? Couldn't you simply draw the scene just like a 'normal voxel engine' (e.g., Comanche, Outcast), and then simulate multiple heights using a vertical c-buffer? That would definitely limit you to 3DOF though... |
||||
|
||||
|
TimothyFarrar Member since: 5/22/2007 From: Westmont, IL, United States |
|||
|
Posted - 9/28/2007 8:36:14 AM |
||||
| Awesome. Software or hardware rendered? Would you care to give some more details on the engine? Is there any way to extend the voxel world size to something large enough for a game? Back in the 16-bit days, there was the ultimate in vector quantization image compression in the form of artist drawn titling. Huge maps in small space. Perhaps that could be done in a voxel way? This, HVR, GPU based ray casting of volume data, but they have a dithering method to removing the artifacts. Might be directly useful for a GPU voxel renderer without the blocky edges... |
||||
|
||||
|
programering Member since: 9/4/2002 From: Gothenburg, Sweden |
|||
|
Posted - 9/28/2007 9:29:49 AM |
||||
| Nice! You're a swed right? |
||||
|
||||
|
spacerat Member since: 10/26/2006 From: Yokohama, Japan |
||||
|
Posted - 9/28/2007 1:07:14 PM |
|||||
| Hi all, thank you for all the comments - I'm really surprised about the positive response :-) Quote: In fact, the rendering method is very similar to Ken Silverman's Voxlap - only that it still misses a lot of his features like accurate cube intersections, MMX and 6DOF. At the moment, destructable scenery is also not possible, as the data structures are not fexbile enough yet. The rendering technique would be able to handle this though. The engine does raycasting - but it's more like a modified height-field renderer, related to the floating horizon algorithm. In Ken's forum, there is more detailed information. The rendering is simply CPU - also single threaded, so multi-core CPU's are not fully exploited yet. (However, this can be added easily) Marching cubes is a good way to get a nice looking polygonal conversion of a voxel volume. However, using LOD might be difficult in case of larger data-sets like 1024^3 as the mesh's LOD-boundaries won't easily fit together. This is why I didnt use this in my old HVox engine. Quote: Mipmaps are required to get the scene complexity - without them it is only possible to raycast an about 1/10th sized scene the same speed. The engine already uses a c-buffer and also does some simple culling by using the floating horizon algorithm (can be seen in the overdraw demo). Most of the overdraw can be prevented by doing this - but its still necessary to further improve the speed by different techniques. Quote: So far, everything is software - there is no hardware acceleration used yet. However, it would be very interesting to use hardware - but I first have to get into CUDA before continuing on that. I also remember the days when most games were tile-based; I liked this style very much, even it was quite simple. In 3D, this should be possible as well. I think the demo shows that there is no limit anymore for the visualization - things left are handling the memory management and having a good voxel painting tool. As the one tile in the demo already has 14MB (without color information), its necessary to further compress it and uncompress it on runtime. I tried Zlib which got it down to 1/4, so this might be an opportunity. The HVR link is quite interesting - I think the only problem to apply this research on my engine is, that I dont have the raw volume data. To increase the quality, usually cubic interpolation is used as I understood, but I cannot easily access the surrounding voxels as it is RLE data.. The solution could be some kind of image-space algorithm or a lookup table per voxel. Quote: Thanks. Actually, I'm a german but I guess my name is swedish. |
|||||
|
|||||
|
PolyVox Member since: 11/24/2002 From: London, United Kingdom |
|||
|
Posted - 9/28/2007 2:06:03 PM |
||||
Quote: Yes, I'm thinking I can't really used mipmapped volumes. The bigger problem with them is that when you update the volume because part of it has been destroyed you then have to update all the mipmap levels. I haven't tried it but I suspect this will be slow. Most likely I'll use some mesh decimation technique for the lower LOD levels. I think both raycasting and marching cubes have their advantages. Raycasting gives you free occlusion culling, and I suspect you can support larger volumes more easily (the meshes get big!). But marching cubes looks nice (shaders) and is fast because you can easily use the GPU. If you're interested you can see my engine here: http://www.ogre3d.org/phpBB2/viewtopic.php?t=27394 Quote: In my engine I break the volume down into blocks and only store the data for those that are non-homogeneous. This is great for gradient estimation, interpolation etc. But I suspect it isn't a good structure for raycasting. Actually I once wrote a volume raycaster for a virtual endoscopy application and didn't get anywhere near the kind of speed you manage! |
||||
|
||||
|
TimothyFarrar Member since: 5/22/2007 From: Westmont, IL, United States |
|||
|
Posted - 9/28/2007 4:45:06 PM |
||||
Quote: BTW, if you did do GPU based 3D volume rendering (say using raycasting), you could provide destroyable voxels with mipmaping. Simply use a FBO (framebuffer object), and map parts of the mipmap of the 3D texture into a framebuffer and update the mipmaps manually. You can select Z level and mipmap level when attaching a 3D texture to a FBO for rendering. If you limit your partial mipmap updates per frame, it shouldn't have as much of a performance hit. |
||||
|
||||
|
PolyVox Member since: 11/24/2002 From: London, United Kingdom |
|||
|
Posted - 9/28/2007 5:26:48 PM |
||||
| You could be right - it's certainly true that the destruction would be limited to a relatively small region each time. I was going to argue that you also need a copy on the CPU for physics, AI, etc, but thinking about it this doesn't need to maintain mipmap levels (they are just for rendering). I certainly think more use could be made of the GPU - and probably there's some scope to do a hybrid raycasting/marching cubes implementation. @spacerat - Do you know whether you RLE data structure could be used/decoded on the GPU? I'm aware of a few lossy techniques for GPU volume compression, but not so sure about lossless. |
||||
|
||||
|
spacerat Member since: 10/26/2006 From: Yokohama, Japan |
|||
|
Posted - 9/29/2007 12:32:53 PM |
||||
Quote: Yes, sure - its my next project. Using CUDA, its possible to do any kind of stuff with the GPU. http://developer.nvidia.com/object/cuda.html Quote: I think I will try to use this kind of technique in a modified way to accelerate the raycasting - it's a good idea. Quote: Updating mipmaps should not be that slow - however, generating a new mesh might be a bit timeconsuming. It would be interesting doing this by CUDA though.. maybe its fast enough. If you target large, static, non-destructible volume data, the GoLD algorithm of siggraph 2005 might be good. For dynamic changes, raycasting is maybe best. To increase the quality for near voxels, marching cubes in the geometry shader can be applied. I remember there were a couple of slides explaining this in one NVidia presentation at the beginning of this year. sven |
||||
|
||||
|
TimothyFarrar Member since: 5/22/2007 From: Westmont, IL, United States |
|||
|
Posted - 9/29/2007 9:57:38 PM |
||||
| More on the topic of voxel rendering. Just got GPU Gems 3 today, and on page 621 it says that GPUs at the time of implementation [of their algorithm] GPUs didn't support writing into slices of a 3D texture, but the NVidia 8000 series does now support it. So if you wanted to do dynamic destruction (the point of voxels right) with 3D textures you are SH4.0/DX10 only. Too bad! So on SM3.0 hardware, you would have to build your 3D volume from parts of a 2D texture for dynamic destruction (and therefore loose your free hardware 3D linear filtering). Assuming you are SH4.0, I still think you could have tremendous wins (performance wise) using raycasting to render your voxels (instead of going to polygons), if you diverge from the standard methods people are using for the medical imaging. The main problem is empty space skipping during the ray marching. If you re-project your previous converged per pixel volume locations from the previous frame then a majority of your empty space will be skipped. This opens a new problem of finding new occluding voxels. If you added a pre-pass of a few random displacement lookups (between the near plane and the reprojected point) per pixel, you would probably effectively find any new occluders. Then using a simple reduction and enlargement pyramid filter, you could dilate the locations of these new occluders to adjacent pixels. Then start the standard ray marching. Also if you use 3D mipmaps, but store the maximum volume alpha (instead of the average), you could do a hierarchical ray march, adapting your step size based on the volume values in the levels of the mipmap. Might converge much faster. Plus with a hierarchical ray march, you could put a flag value in the pixel values of the mipmaps to note that the volume data lower (more detailed) in the volume mipmap tree was invalid. This would enable you to do huge updates on the volume quickly and spread them over many frames. Example, large explosion, just update the upper mip levels, then later get to the lower more detailed levels. Or take it a step more advanced and update the volume based on visibility. Also also, you can get free temporal anti-aliasing by offseting your ray directions randomly by fractional pixel values differently each frame. Seriously, I think that with the GeForce 8800/8600 the performance is there for a fully raycasted voxel rendered game with fully dynamic geometry. [Edited by - TimothyFarrar on September 29, 2007 9:57:14 PM] |
||||
|
||||
|
spacerat Member since: 10/26/2006 From: Yokohama, Japan |
|||
|
Posted - 9/29/2007 11:38:37 PM |
||||
| Actually, I already did a simple raycast-test with CUDA on a heightmap. In the example, it was possible to shoot the ray for each of the 512 colums about 25000 pixels to the depth at about 20 fps on a GeForce 8800 GTS. This is about 10x-20x more than my upper demo does, so it might really be an opportunity for completely voxelized 3D-games with high quality.  |
||||
|
||||
|
robotichrist Member since: 4/23/2006 From: Houghton, MI, United States |
|||
|
Posted - 10/1/2007 6:47:27 PM |
||||
| Good to see that you are still at it! I am a very big fan of your work, especially the volumetric surface reconstruction algorithm. Have you considered trying to support dynamic data sets, such as deformable objects or fluids? I realize that RLE rendering might be a poor choice for these sorts of systems, but perhaps with some clever modifications it might be possible to hack a partial solution out. -Mik |
||||
|
||||
|
spacerat Member since: 10/26/2006 From: Yokohama, Japan |
|||
|
Posted - 10/2/2007 9:49:39 AM |
||||
| Update: today I finished the basic CUDA implementation of the renderer. You'll find the new executables along with the old ones in the former rar-archive that was already linked at the beginning. GPU is about 2x-3x as fast as CPU, but I hope to increase it by further GPU specific optimizations. Quote: Many thanks for the appreciation! Yes. fluids and deformations are indeed a big challenge - especially with RLE data. Of course its easy to do some 2 1/2 D fluid simulation, where waves are generated by changing the height of the water surface, but a complete 3D thingy is not really easy.. If Voxels might be mixed with particles, this could be an idea. As for deformation - like skeletal animation with voxel data - would be interesting, but I doubt its efficient with the current RLE structure.. Its really rigid. Something that might be applicable tough is rendering of clouds or smoke - it could be worth a try. -Sven |
||||
|
||||
 |
Tom GDNet+ Member since: 6/13/2000 From: Elkhart, IN, United States |
|||
Posted - 11/17/2007 12:54:25 PM |
||||
| This is absolutely astounding. Brings back memories of Outcast, which I still consider a technological masterpiece. Those trees you have are particularly remarkable. Have you considered interpolating voxels that are near the camera (where voxel size exceeds pixel size) to smooth out the scene? |
||||
|
||||
|
RAZORUNREAL Member since: 1/18/2004 From: Auckland, New Zealand |
|||
|
Posted - 11/18/2007 12:21:40 AM |
||||
| I've been doing some voxel stuff lately. Mine has interpolation and 6 degrees of freedom, but by the nature of the algorithm (a form of raycasting) I can't run length encode it, so the largest volume I've tried is 512^3. I just got basic destruction going. You can read a bit about it here, but that's before destruction was added. ___________________________________________________ David Olsen If I've helped you, please vote for PigeonGrape! |
||||
|
||||
|
spacerat Member since: 10/26/2006 From: Yokohama, Japan |
|||
|
Posted - 11/28/2007 9:03:08 AM |
||||
Quote: Do you have an executable of the new algorithm on your page ? The older version you have online looks still interesting though. According to the memory usage, its a 256^3 volume. If you didnt RLE it, its much easier with 6DOF, but you'll run out of memory quickly. The method I use so far is identical to Ken Silvermans Voxlap algorithm. You might already come over it http://www.advsys.net/ken/voxlap.htm http://www.jonof.id.au/forum/index.php?board=9.0 I will continue to add 6DOF as soon as I have finished two further publications that keep me busy these days. As for the normal vectors, I used a more general approach to compute them from a 5x5x5 voxel window. Unfortunately this still produces a lot of artifacts - I think I will therefore add smoothing of neighbouring normals to improve the quality. Quote: The problem with RLE is, that its not possible to easily interpolate in voxelspace, as it adds a large overhead.. In screenspace it is possible, but not as nice. The interpolation you're doing, Razor, looks good - I guess its similar to the GPU'S texture filtering. But the window of your demo is really too small.. ;-) By the way, here a screenshot of the latest version: 40kx1kx40k voxels, rendered in a 512x512 window on a GF8800 @ 30-40fps with dynamic lighting.  -Sven [Edited by - spacerat on November 28, 2007 8:03:40 AM] |
||||
|
||||
|
spacerat Member since: 10/26/2006 From: Yokohama, Japan |
|||
|
Posted - 3/2/2008 12:19:29 PM |
||||
| Updated the Demo - now its 5DOF. voxels.blogspot.com Note: you might need CUDA 1.1 to run the demo [Edited by - spacerat on February 19, 2009 10:19:54 AM] |
||||
|
||||
All times are ET (US) |
Last Image Next Image |
|
