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: Nicolas Bonneel on 26 May 2010 17:10 Skybuck Flying wrote: > "Nicolas Bonneel" <nbonneel(a)cs.ubc.ca> wrote in message > news:4BFC9ECA.7090204(a)cs.ubc.ca... >> Skybuck Flying wrote: >>> Is that the same concept as "splat" ? ;) :) >> >> no. Splats are 2D. > > Then I guess it's the same since the vector balls are 2D as well, just their > coordinates are 3D. ok. Then every particle system displaying some sprites are the same as splat. In fact, anything drawing pixels on screen are the same as splat... No. Splat are oriented 2D ellipses which cover a surface to be drawn. It's not a particle system, it's not "some pixels drawn on screen". The demo you showed me is just a particle system as has been done for decades. This is not point based rendering.
From: Nicolas Bonneel on 26 May 2010 17:38 Skybuck Flying wrote: > I scanned through all the documents and the compression problem remains. > > Bye, > Skybuck. you "scanned through". good. now read. I swear it will take you more than a day to be able to speak about it. I don't say "everything is solved". I just say there *are* efficient compression schemes - as in the links I sent, with octree based compression. So maybe stills things have to be done to reach Shannon limit, but if people *are* able to render billionS of voxels, it *means* it is sufficiently compressed for interesting use with current hardware. If it was *not* compressed, a 8192^3 voxelization would take 2TeraBytes (with just 1 float opacity per voxel, without any color) which obviously does not fit in the gpu memory.
From: Skybuck Flying on 26 May 2010 18:19 "Nicolas Bonneel" <nbonneel(a)cs.ubc.ca> wrote in message news:htk4de$1a4$1(a)swain.cs.ubc.ca... > Skybuck Flying wrote: >> I scanned through all the documents and the compression problem remains. >> >> Bye, >> Skybuck. > > you "scanned through". good. now read. > I swear it will take you more than a day to be able to speak about it. > > I don't say "everything is solved". I just say there *are* efficient > compression schemes - as in the links I sent, with octree based > compression. So maybe stills things have to be done to reach Shannon > limit, but if people *are* able to render billionS of voxels, it *means* > it is sufficiently compressed for interesting use with current hardware. > If it was *not* compressed, a 8192^3 voxelization would take 2TeraBytes > (with just 1 float opacity per voxel, without any color) which obviously > does not fit in the gpu memory. Perhaps, but perhaps the renderer is also "cheating" by using the CPU to do the decompression. And if I recall correctly it does seem to be cheating by using the CPU to do the decompression. The problem with that is that games would not have enough CPU power level to do the game's logic. Bye, Skybuck.
From: Nicolas Bonneel on 26 May 2010 18:25 Skybuck Flying wrote: > "Nicolas Bonneel" <nbonneel(a)cs.ubc.ca> wrote in message >> I don't say "everything is solved". I just say there *are* efficient >> compression schemes - as in the links I sent, with octree based >> compression. So maybe stills things have to be done to reach Shannon >> limit, but if people *are* able to render billionS of voxels, it *means* >> it is sufficiently compressed for interesting use with current hardware. >> If it was *not* compressed, a 8192^3 voxelization would take 2TeraBytes >> (with just 1 float opacity per voxel, without any color) which obviously >> does not fit in the gpu memory. > > Perhaps, but perhaps the renderer is also "cheating" by using the CPU to do > the decompression. Instead of saying "perhaps", read it!!!!!! If the data was decompressed on the CPU, there would be no way to send that amount of data on the fly to the GPU. They achieve at worse 20fps on this old hardware. If you meant "compressed", then it is completely fine to compress data on the CPU. > > And if I recall correctly it does seem to be cheating by using the CPU to do > the decompression. > > The problem with that is that games would not have enough CPU power level to > do the game's logic. This is mainly a gpu algo, it was in 2007, and didn't saturate the cpu with computations. Now, I'll stop responding until you read and understand at least 5-6 papers about whatever you're talking of.
From: Skybuck Flying on 26 May 2010 18:38
"Nicolas Bonneel" <nbonneel(a)cs.ubc.ca> wrote in message news:htk2nn$vh8$1(a)swain.cs.ubc.ca... > Skybuck Flying wrote: >> "Nicolas Bonneel" <nbonneel(a)cs.ubc.ca> wrote in message >> news:4BFC9ECA.7090204(a)cs.ubc.ca... >>> Skybuck Flying wrote: >>>> Is that the same concept as "splat" ? ;) :) >>> >>> no. Splats are 2D. >> >> Then I guess it's the same since the vector balls are 2D as well, just >> their coordinates are 3D. > > No. Splat are oriented 2D ellipses What's the difference then ? It seems almost the same. The UltraForce demo uses "balls/ellipse-like-things". It even does a little bit of lightning to make the back dark and the front lighter... Bye, Skybuck. |