RLE acceleration hardware for nextgen graphics ?! ;) :)
|
Prev: FAKE CONFERENCE 2nd call - INFORMATICS 2010: submissions until 31 May 2010
Next: Micro Men on BBC4 today 22:30
From: Skybuck Flying on 21 May 2010 19:59 "Nicolas Bonneel" <nbonneel(a)cs.ubc.ca> wrote in message news:ht6t7g$dj1$1(a)swain.cs.ubc.ca... > 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.
From: Nicolas Bonneel on 21 May 2010 21:04 Skybuck Flying wrote: > "Nicolas Bonneel" <nbonneel(a)cs.ubc.ca> wrote in message > news:ht6t7g$dj1$1(a)swain.cs.ubc.ca... >> 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.).
From: Nicolas Bonneel on 21 May 2010 21:18 Skybuck Flying wrote: > "Nicolas Bonneel" <nbonneel(a)cs.ubc.ca> wrote in message > news:ht6t7g$dj1$1(a)swain.cs.ubc.ca... >> 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.
From: Skybuck Flying on 23 May 2010 22:52 "Nicolas Bonneel" <nbonneel(a)cs.ubc.ca> wrote in message news:ht7aia$pg0$1(a)swain.cs.ubc.ca... > Skybuck Flying wrote: >> "Nicolas Bonneel" <nbonneel(a)cs.ubc.ca> wrote in message >> news:ht6t7g$dj1$1(a)swain.cs.ubc.ca... >>> 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.
From: Skybuck Flying on 23 May 2010 22:57
"Nicolas Bonneel" <nbonneel(a)cs.ubc.ca> wrote in message news:4BF730EB.6070001(a)cs.ubc.ca... > Skybuck Flying wrote: >> "Nicolas Bonneel" <nbonneel(a)cs.ubc.ca> wrote in message >> news:ht6t7g$dj1$1(a)swain.cs.ubc.ca... >>> 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. |