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 are:

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 shitted on his face ?

I think working together with the good man would be a smart idea !

Bye,
Skybuck =D

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 ()

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.

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/

"Nicolas Bonneel" <> wrote in message
news:ht6t7g$dj1$...
> 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.

"Nicolas Bonneel" <> wrote in message
news:ht6t7g$dj1$...
> 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.

Skybuck Flying wrote:
> "Nicolas Bonneel" <> wrote in message
> news:ht6t7g$dj1$...
>> 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.).

Skybuck Flying wrote:
> "Nicolas Bonneel" <> wrote in message
> news:ht6t7g$dj1$...
>> 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.

"Nicolas Bonneel" <> wrote in message
news:ht7aia$pg0$...
> Skybuck Flying wrote:
>> "Nicolas Bonneel" <> wrote in message
>> news:ht6t7g$dj1$...
>>> 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.

"Nicolas Bonneel" <> wrote in message
news:...
> Skybuck Flying wrote:
>> "Nicolas Bonneel" <> wrote in message
>> news:ht6t7g$dj1$...
>>> 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.