If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
RLE acceleration hardware for nextgen graphics ?! ;) :)
Hello,
Last time I saw/heared/read John Carmack (the famous programmer of Doom and Quake) talking about nextgen graphics rendering technology he showed a demo of "voxel/volume" based rendering. Such voxel's/volume's based rendering would probably need special hardware to quickly compresses and decompress voxel/volume's into for example RLE streams. Thus I expect if volume rendering is to become a reality for games for new hardware to be designed ?! =D Though suddenly I do remember "octal tree's and all of that stuff"... maybe that's too difficult/complex to do in hardware... and maybe RLE is much easier to do... Question left open a 1. Do the volumes need to be rotated ? 2. What other possibilities are there for hardware acceleration of "volume-rendering" based graphics" ?!? 3. Is NVIDIA and/or ATI/AMD heading in the wrong direction by focussing to much on "programmable hardware" / "parallel software" and should they be concentrating more on working together with John Carmack to try and bring the next graphics technology to reality ?!? 4. Are they already secretly working with John Carmack... or have they somehow ****ted on his face ? I think working together with the good man would be a smart idea ! Bye, Skybuck =D |
#2
|
|||
|
|||
RLE acceleration hardware for nextgen graphics ?! ;) :)
On Thursday 20 May 2010 23:12, Skybuck Flying wrote:
Last time I saw/heared/read John Carmack (the famous programmer of Doom and Quake) talking about nextgen graphics rendering technology he showed a demo of "voxel/volume" based rendering. ... 1. Do the volumes need to be rotated ? I sure they do: either because of changes in world state (e.g. the person is wheeling around) or changes in view point (e.g. I'm turning to look left). -paul- -- Paul E. Black ) |
#3
|
|||
|
|||
RLE acceleration hardware for nextgen graphics ?! ;) :)
I am not so sure about that:
Two possibilities to not have to rotate: 1. Camera view changes... instead of rotating the entire world, rotate the camera around the static objects. And cast rays from the camera into the objects. 2. Instead of rotating objects, keep track of there rotations and when calculations need to be done like rays entering into the object... try to use an imaginery sphere around the object... when the "rays" enter the sphere rotate the ray around the sphere... and then let the ray continue into the object as normal. These two solutions would/could probably solve the rotation problem. Therefore assuming the volume is accessible from x,y,z from any direction vector no rotations would be needed except the rays going into the volume. Which could be a lot less rotations then rotating entire volume's. Ultimately graphics cards would need some api to retrieve a voxel like so: UncompressVoxel( VolumeObject, VoxelX, VoxelY, VoxelZ ); Then such an api could be used by ray-tracers to traverse the volume. Even better would be ray-tracers which can trace/traverse a ray through a volume and detect for example a collision or so: DetectVoxelCollission( in: VolumeObject, RayStartX, RayStartY, RayStartZ, RayEndX, RayEndY, RayEndZ, out: VoxelX, VoxelY, VoxelZ ); Which could be usefull for "collision detection". Also for drawing the scene a slightly extended version: ReturnVoxelCollission( in: VolumeObject, RayStartX, RayStartY, RayStartZ, RayEndX, RayEndY, RayEndZ, out: VoxelX, VoxelY, VoxelZ, VoxelColor ); Which would also return the voxel's color... In case voxel's have/needed other properties then it could also return the entire voxel like so: ReturnVoxelCollission( in: VolumeObject, RayStartX, RayStartY, RayStartZ, RayEndX, RayEndY, RayEndZ, out: VoxelX, VoxelY, VoxelZ, VoxelData ); So which these api's the hardware could do "ray traversal" entire in hardware/memory... and uncompress voxel's as necessary. Bye, Skybuck. |
#4
|
|||
|
|||
RLE acceleration hardware for nextgen graphics ?! ;) :)
Skybuck Flying wrote:
2. What other possibilities are there for hardware acceleration of "volume-rendering" based graphics" ?!? again I avertise for the GigaVoxel paper... http://artis.imag.fr/Publications/2009/CNLE09/ |
#5
|
|||
|
|||
RLE acceleration hardware for nextgen graphics ?! ;) :)
"Nicolas Bonneel" wrote in message ... Skybuck Flying wrote: 2. What other possibilities are there for hardware acceleration of "volume-rendering" based graphics" ?!? again I avertise for the GigaVoxel paper... http://artis.imag.fr/Publications/2009/CNLE09/ The word compress is found 1 time. The word compression is found 0 times. How does it compress volumes ? Can it compress for example a "(hollow) hull" to mere kilobytes ? Bye, Skybuck. |
#6
|
|||
|
|||
RLE acceleration hardware for nextgen graphics ?! ;) :)
"Nicolas Bonneel" wrote in message ... Skybuck Flying wrote: 2. What other possibilities are there for hardware acceleration of "volume-rendering" based graphics" ?!? again I avertise for the GigaVoxel paper... http://artis.imag.fr/Publications/2009/CNLE09/ Also the API I mentioned is not only for gp/gpgpu... The CPU might also need modest ammounts of information from volumes/voxels. The document at the link seems to be mostly about "rendering"... and not so much about "retrieving information from volume's". The API I mentioned would use the GPU's capabilities to return information to the CPU. Bye, Skybuck. |
#7
|
|||
|
|||
RLE acceleration hardware for nextgen graphics ?! ;) :)
Skybuck Flying wrote:
"Nicolas Bonneel" wrote in message ... Skybuck Flying wrote: 2. What other possibilities are there for hardware acceleration of "volume-rendering" based graphics" ?!? again I avertise for the GigaVoxel paper... http://artis.imag.fr/Publications/2009/CNLE09/ The word compress is found 1 time. The word compression is found 0 times. How does it compress volumes ? Can it compress for example a "(hollow) hull" to mere kilobytes ? To understand that, it requires more than pressing F3 to search for words in the document. They also give a good review of the previous work which should allow you to find all the infos you want, including a STAR report [EHK*06]. Finally, storing hollow closed surfaces as volumetric data instead of polygons or parametric surfaces is not that clever (except if you're dealing with implicit surfaces simulation etc.). |
#8
|
|||
|
|||
RLE acceleration hardware for nextgen graphics ?! ;) :)
Skybuck Flying wrote:
"Nicolas Bonneel" wrote in message ... Skybuck Flying wrote: 2. What other possibilities are there for hardware acceleration of "volume-rendering" based graphics" ?!? again I avertise for the GigaVoxel paper... http://artis.imag.fr/Publications/2009/CNLE09/ Also the API I mentioned is not only for gp/gpgpu... You didn't mention any API... did you ? The CPU might also need modest ammounts of information from volumes/voxels. The document at the link seems to be mostly about "rendering"... and not so much about "retrieving information from volume's". Your whole post was about volume rendering... isn't it ? This paper deal both with the acceleration structure (octree), the way to use and update it efficiently on the GPU (during camera motion for example, if the goal is rendering) and the rendering itself (ray marching and filtering). The API I mentioned would use the GPU's capabilities to return information to the CPU. GPU-CPU transfers are usually to be avoided. What kind of information do you want to transfer ? The final image (- then it's volume rendering) ? "Some" results of "some" computations ?... it's vague. |
#9
|
|||
|
|||
RLE acceleration hardware for nextgen graphics ?! ;) :)
"Nicolas Bonneel" wrote in message ... Skybuck Flying wrote: "Nicolas Bonneel" wrote in message ... Skybuck Flying wrote: 2. What other possibilities are there for hardware acceleration of "volume-rendering" based graphics" ?!? again I avertise for the GigaVoxel paper... http://artis.imag.fr/Publications/2009/CNLE09/ The word compress is found 1 time. The word compression is found 0 times. How does it compress volumes ? Can it compress for example a "(hollow) hull" to mere kilobytes ? To understand that, it requires more than pressing F3 to search for words in the document. I looked through it... it seems about some kind of "block" compression. Quite complex too... with nodes and such. They also give a good review of the previous work which should allow you to find all the infos you want, including a STAR report [EHK*06]. ? Finally, storing hollow closed surfaces as volumetric data instead of polygons or parametric surfaces is not that clever (except if you're dealing with implicit surfaces simulation etc.). Polygons need to be rendered/pixelated with complex formula's and routines. Voxel's can be ray-traced and massively parallel too ?!? Like John Carmack said: When the polygons become that small it doesn't make much sense to use polygons anymore... Points is not an option those too small. Voxels seems ok, they lie in a grid... so their more like boxes. Bye, Skybuck. |
#10
|
|||
|
|||
RLE acceleration hardware for nextgen graphics ?! ;) :)
"Nicolas Bonneel" wrote in message ... Skybuck Flying wrote: "Nicolas Bonneel" wrote in message ... Skybuck Flying wrote: 2. What other possibilities are there for hardware acceleration of "volume-rendering" based graphics" ?!? again I avertise for the GigaVoxel paper... http://artis.imag.fr/Publications/2009/CNLE09/ Also the API I mentioned is not only for gp/gpgpu... You didn't mention any API... did you ? See follow-up post. The CPU might also need modest ammounts of information from volumes/voxels. The document at the link seems to be mostly about "rendering"... and not so much about "retrieving information from volume's". Your whole post was about volume rendering... isn't it ? No not really, it's about nextgen-hardware to speed-up the use of "volumes/voxels-based technology". Rendering is just a part of it. This paper deal both with the acceleration structure (octree), the way to use and update it efficiently on the GPU (during camera motion for example, if the goal is rendering) and the rendering itself (ray marching and filtering). As long as it renders one or two objects that not very impressive... It needs to render entire scenes... and then the scenes need to have physics as well. The API I mentioned would use the GPU's capabilities to return information to the CPU. GPU-CPU transfers are usually to be avoided. What kind of information do you want to transfer ? The compressed voxels/volumes, and just some coordinates for lines. The final image (- then it's volume rendering) ? That perhaps to after the rendering. "Some" results of "some" computations ?... it's vague. "Compression/Decompression" computations. Voxels/Volumes can be compressed well, but need to be decompressed to do computations on... I don't think CPU's are suited to handle that kind of work... Nor do graphics cards seem really suited for it... Perhaps new technology needs to be created which focus on decompressing the volumes very rapidly to allow computations on them. The computations could be done inside the new technology as well so that the big volumes don't have to be transferred. The compressed volumes could stay inside the new technology, the uncompressed can simply be thrown away/overwritten. The volumes get decompressed only when needed. Bye, Skybuck. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
HD 2400 Pro AGP Hardware Acceleration | Jeff OTF | Ati Videocards | 3 | May 2nd 08 06:09 PM |
Disabling hardware acceleration | GRL | Nvidia Videocards | 5 | April 19th 08 06:29 PM |
How to get hardware acceleration in OpenGL? | Robert Gault | Nvidia Videocards | 12 | April 17th 06 11:11 PM |
hardware acceleration with ati radeon ? | O.L. | Ati Videocards | 2 | February 2nd 04 03:04 PM |
Hardware Acceleration | Speeker | Nvidia Videocards | 8 | September 4th 03 06:59 AM |