Forum archive
raycasting on the gpu
- Lately my interest in voxels was revived after seeing a realtime voxel raytracer in action: http://rearview.sourceforge.net/
The quality is kinda crap, but for what it does the speed is quite good (it even does realtime global illumination!).
When I searched a bit around on google I found that there are several hardware accelerated voxel rendering implementations around, to list a couple:
http://graphics.cs.ucf.edu/GPUassistedGI/index.php (see interactive raycasting on the gpu) They have a demo online which shows a nicely interpolated voxel model in a polygon environment.
http://www.vis.uni-stuttgart.de/~engel/pre-integrated/
(runs at about 100fps on my pc)
Ken, I know you kinda abandonned the idea of voxel rendering for games. But given these developments do you think it will be feasable? Have you ever expirimented with these techniques before?
I just can't let go of the idea how cool it would be to have true destructable objects in a game ;) - Hi,
There are also some SIGGRAPH course presentation slides available online, regarding the real-time volume rendering on graphics hardware.
http://www.cs.utah.edu/~jmk/sigg_crs_02/courses_0067.html
http://www.vrvis.at/via/resources/course-volgraphics-2004/
And recently, the book "Real-Time Volume Graphics" was just released.
http://www.amazon.com/Real-time-Graphics-Klaus-Engel/dp/1568812663/
I haven't implemented my own real-time volume renderer, but due to the nature of volume graphics, I think it is quite difficult to employ the GPU-based volume graphics on games without any system-memory-to-VRAM data streaming architecture.
Therefore, MegaGeometry is now highly expected. :) - Thanks for those links!
but due to the nature of volume graphics, I think it is quite difficult to employ the GPU-based volume graphics on games without any system-memory-to-VRAM data streaming architecture.
Wouldn't it be possible to keep the volume data in vram? In the demo's above they do it for static data, but maybe its contents be changed with some shader tricks?Therefore, MegaGeometry is now highly expected.
I couldn't find any information on MegaGeometry, there was some wiki page about MegaTexture but that didn't gave away too much info neither. How would MegaGeometry overcome the issues there are with hardware volumetric rendering? - I've seen the demo to, it's quite impressive. The papers are interesting too, I read them a couple of weeks ago.
The idea of a real-time (illuminated) volume rendering powered game could become reality with nowaday's shader capabilities.
Anyways, it should be possible to store the volume data in the graphics card's memory, but when you do, it'll eat a lot of memory. That's why MegaGeometry is mentioned.
I'm currently trying to build a primitive voxel engine with GL_POINTS and raycast shaders instead. Anyways, it should be possible to store the volume data in the graphics card's memory, but when you do, it'll eat a lot of memory. That's why MegaGeometry is mentioned.
I see, sounds promising. I couldn't find any technical description of MegaTextures / MegaGeometry though, just some interviews on how spiffy it will be.. are there any technical details or even demos available?- Not sure.
But just to give you an example of the sizes of volume data: the skull in the ucf raycasting demo is 256x256x115x1 (= 7MB, depth) + 256x256x115x4 (= 30MB, normals) in size. - Ok, did some reading on megatextures.
From what I've understand (nothing confirmed, just based upon ideas how this might work) it's just a plain streaming technology:
have one big map on disc (compressed), determine an area of interest, uncompress specific part from map, cut it up into tiles and put this into system ram, copy only necesary tiles to vram. When the area of interest changes this process repeats.
So Im not sure how this would be applicable to volume data. Surface voxels would be our area of interest, but thats still an awfull lot for your average object... - *bump*
Anyone out there with some more knowledge about megageometry that could verify this? - I think it's very interesting to see how fast that pre-integrated demo runs, although it was written in 2001 and still uses the fixed function pipelines (registry combiners, not custom vertex/pixel shaders).
I know it uses 2D texture slices along with some tricks, and it pretty much faster than anything else I've seen. That's without any special lighting effects included though.
It has potential.. which is nice. Gonna try and see if I can implement my own version of this.