Yes! Thank you, that hint + google.com gave me this link

http://www.acm.org/jgt/papers/KarabassiEtAl99b/


Dave Dunn wrote:

> Could this be what you are looking for?
> 
>  A Fast Depth-Buffer-Based Voxelization Algorithm

Post a reply to this message

The VolVis link off that page also has related images.
http://www.cs.sunysb.edu/~vislab/volvis_home.html

So the steps are

Generate the matrix in POV via a 3d render.
Encode the matrix with compression.
View the Matrix from any point.

No fancy lighting of the Volume is required as the original 3d render will 
supply this data. A good radiosity render should be a "fun" object to look 
at.

Daniel Matthews wrote:

> Yes! Thank you, that hint + google.com gave me this link
> 
> http://www.acm.org/jgt/papers/KarabassiEtAl99b/
> 
> 
> Dave Dunn wrote:
> 
>> Could this be what you are looking for?
>> 
>>  A Fast Depth-Buffer-Based Voxelization Algorithm

Post a reply to this message

http://www.google.com/search?q=wavelet+voxel

Christopher James Huff wrote:

> MegaPOV has a feature that can be used to create 3D density files, but
> that is purely geometry and uncompressed. Your idea sounds
> interesting...I think it would have to be another rendering engine
> attached to the same parser, though.
> I think it would be possible, but a huge amount of work.
> 
> BTW, do you have any information on voxel file formats? I've been
> working on a voxel file editor...
> 
> --
>  --
> Christopher James Huff <chr### [at] maccom>

Post a reply to this message

In article <141### [at] 3-enet>, dan### [at] 3-enet says...

> I often wonder what it would be like to wander/look around inside some of 
> the first class work on from the IRTC.
> 
> Think of it as extreme POV-VRML

What about the camera-location-dependent features: reflections, 
refractions, highlights...

You can't precalculate and store them all (you would have to this for 
every possible camera location) and you can't recalculate them later 
on-the-fly.

Lutz-Peter

Post a reply to this message

Each voxel is a spherical map (possible very low res)
The lowest res would be a six sided shape with each side having 16 bit 
vales for RGB or HLS. LOD would determine the map size?

The rendered view is an interpolation between these values, which are 
chosen from the map points that are facing the camera, with the values of 
the map been interpolated too, based on the normal of the map values 
relative to the camera. i.e. a cube map would have three sides facing the 
camera most of the time so the resulting value will be a mix of the three.


Lutz-Peter Hooge wrote:

> In article <141### [at] 3-enet>, dan### [at] 3-enet says...
> 
>> I often wonder what it would be like to wander/look around inside some of
>> the first class work on from the IRTC.
>> 
>> Think of it as extreme POV-VRML
> 
> What about the camera-location-dependent features: reflections,
> refractions, highlights...
> 
> You can't precalculate and store them all (you would have to this for
> every possible camera location) and you can't recalculate them later
> on-the-fly.
> 
> Lutz-Peter

Post a reply to this message

To see this as wavelets in a simple case such as the lowres cube map, 
imagine a 1D wave for each face on each voxel.
Then you have a 2D grid of waves running from top to bottom, another from 
left to right and another from front to back.
This would be for a monochrome image, so multiply by 3 to encode the HLS 
values.

Daniel Matthews wrote:

> Each voxel is a spherical map (possible very low res)
> The lowest res would be a six sided shape with each side having 16 bit
> vales for RGB or HLS. LOD would determine the map size?
> 
> The rendered view is an interpolation between these values, which are
> chosen from the map points that are facing the camera, with the values of
> the map been interpolated too, based on the normal of the map values
> relative to the camera. i.e. a cube map would have three sides facing the
> camera most of the time so the resulting value will be a mix of the three.
> 
> 
> Lutz-Peter Hooge wrote:
> 
>> In article <141### [at] 3-enet>, dan### [at] 3-enet says...
>> 
>>> I often wonder what it would be like to wander/look around inside some
>>> of the first class work on from the IRTC.
>>> 
>>> Think of it as extreme POV-VRML
>> 
>> What about the camera-location-dependent features: reflections,
>> refractions, highlights...
>> 
>> You can't precalculate and store them all (you would have to this for
>> every possible camera location) and you can't recalculate them later
>> on-the-fly.
>> 
>> Lutz-Peter

Post a reply to this message

http://www.3dcompression.com/index.phtml

Christopher James Huff wrote:

> MegaPOV has a feature that can be used to create 3D density files, but
> that is purely geometry and uncompressed. Your idea sounds
> interesting...I think it would have to be another rendering engine
> attached to the same parser, though.
> I think it would be possible, but a huge amount of work.
> 
> BTW, do you have any information on voxel file formats? I've been
> working on a voxel file editor...
> 
> --
>  --
> Christopher James Huff <chr### [at] maccom>

Post a reply to this message

In article <141### [at] 3-enet> , Daniel Matthews <dan### [at] 3-enet>  
wrote:

> How complex a task would it be to patch POV so that is could render a scene
> to a wavelet compressed voxel (3d pixel) file.

Well, there is a function that can determine if a point is inside an object
or not.  That would work for most but not all objects.  Determining the
color of an object at just about any position should be possible as well,
also it would not be perfect (given that usually nobody assigns interiors to
solid objects and one would have to use the texture an artist only assumed
would be used for the outside - nevertheless, as most textures are defined
at any point in space, it would still be possible to make up a color for
those invisible voxels as well).

Which leaves the compression.  I never implemented any wavelet based
compression, but from what I have read, those are usually a bit more complex
than a simple JPEG or PNG/ZIP compressor to implement.  So unless someone
has a library for this, I would assume implementing the code for the
compression would take by far most of the time.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <733### [at] 3-enet>, Daniel Matthews <dan### [at] 3-enet> 
wrote:

> http://www.3dcompression.com/index.phtml

Thanks for this and the other links, they should be useful...

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

With Povscript's (3.5) trace() function it should be possible to 'render' a
scene into a 3d-array of intersections and save that to disk. Another
program or util should convert that huge file into a 3d wavelet compressed
file.

By the way: I'm a big fan of wavelets.

Post a reply to this message