POV-Ray : Newsgroups : povray.programming : Using POV to render voxels Server Time
23 Dec 2024 02:15:05 EST (-0500)
  Using POV to render voxels (Message 1 to 8 of 8)  
From: Peskanov
Subject: Using POV to render voxels
Date: 20 May 2003 18:50:02
Message: <web.3ecab077a576dc40da05be620@news.povray.org>
Hello everybody;
I have programmed a 3D voxel renderer (like in medical tomography) and now I
am looking for good quality scenes to test.
A friend, Jaime Vives, has some really nice scenes in POV, and I was
wondering if I could use POV to render these in the voxel instead of in a
flat 2d image.
I have seen a thread about voxel & pov, but it does not contain what I am
looking for.

I have thinked a method to acomplish voxel rendering with any raytracer, but
I don't know the feasibility of my idea under the POV framework.
I need:
- To cast parallel rays over the scene.
- To know all points cutted by the ray in a known distance. Only for "empty"
objects, not volumetric object simulating clouds, etc...
- To set a different ray of incidence to get the ligth. Or to set a general
light and discard light comming from reflection. I want to obtain the cross
of the ray and the object, but the ray does not come from the camera! The
angle of the parallel rays must not add light information.

With these 3 points, I think I can render a good looking voxel scene.
Can any POV guru offer some advice? I have much experience in C & C++, and
in RT 3D engines, but little in raytracers.

BTW, I am using Mac OS X. I hope there are no serious problems with the
sources...


Post a reply to this message

From: Christopher James Huff
Subject: Re: Using POV to render voxels
Date: 23 May 2003 20:06:31
Message: <cjameshuff-97617C.19073323052003@netplex.aussie.org>
In article <web.3ecab077a576dc40da05be620@news.povray.org>,
 "Peskanov" <nomail@nomail> wrote:

> I have programmed a 3D voxel renderer (like in medical tomography) and now I
> am looking for good quality scenes to test.
> A friend, Jaime Vives, has some really nice scenes in POV, and I was
> wondering if I could use POV to render these in the voxel instead of in a
> flat 2d image.
> I have seen a thread about voxel & pov, but it does not contain what I am
> looking for.

You want to render a POV scene to a voxel field? This can not be done 
directly, but there are several ways you could approach it. You could 
put the objects to be rendered in the voxel field into a union and 
intersect them with a pair of planes to get a "slice" of the scene, you 
could then render several frames with the planes progressing along the 
object, and combine the frames into a final voxel field for display.

This all requires a lot of manual modifications to the scene, though, 
and it sounds like you want some kind of patch that gives voxel output. 
This is an interesting idea, and I can think of a couple possible 
methods. I'm not clear on how much lighting calculations you want to do 
immediately or how realistic your voxel rendering is to be.

One possibility is to march through the lattice of voxels covering the 
scene, and for each voxel compute the average of the pigments for each 
object that contains that point. This will lose any infinitely thin 
objects, for those you would need to use raytracing. By collecting the 
pigment information and saving light source information to a file for 
your voxel renderer, you could get a shaded color view of the scene. You 
could save more texture information to get a more realistic rendering, 
but at the cost of a lot of storage.
Another possibility is to do some sort of palleted voxel field, where 
you store a texture ID for the voxels and the texture information 
separately. This might be much more memory efficient, but slower and 
more complex to render.

BTW, what format are you using? I've been working on an extended density 
file format for my own experimentation, maybe you would find it 
interesting.


> BTW, I am using Mac OS X. I hope there are no serious problems with the
> sources...

If you are using the GUI version, you may want to look into MacMegaPOV, 
which has a GUI that works better under OS X than the official version. 
The command line version can be compiled for OS X, but it involves some 
makefile hacking. It would probably be easiest to install it through 
Fink. All this only applies if you are not making your own patch...if 
you are patching, the path of least resistance would be to compile the 
command line version using the free development tools.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/


Post a reply to this message

From: Ben Chambers
Subject: Re: Using POV to render voxels
Date: 24 May 2003 18:53:47
Message: <3ecff7fb@news.povray.org>
"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cja### [at] netplexaussieorg...
> One possibility is to march through the lattice of voxels covering the
> scene, and for each voxel compute the average of the pigments for each
> object that contains that point. This will lose any infinitely thin
> objects, for those you would need to use raytracing.

Since you need to do raytracing anyway, why not for each ray calculate the
intersections between _all_ objects (not just the nearest), and store them
in a queue?  Then, this queue of intersections could be processed into a
voxel format.

...Chambers


Post a reply to this message

From: Peskanov
Subject: Re: Using POV to render voxels
Date: 26 May 2003 06:35:01
Message: <web.3ed1ed2f1187fffdda05be620@news.povray.org>
Ben Chambers wrote:

>Since you need to do raytracing anyway, why not for each ray calculate the
>intersections between _all_ objects (not just the nearest), and store them
>in a queue?  Then, this queue of intersections could be processed into a
>voxel format.

That was exaclty my idea. I intend to do this for the 3 axis so I don't
loose any plane.
What I would like is some hints about which functions should I look, as I am
new to POV sources.


Post a reply to this message

From: Peskanov
Subject: Re: Using POV to render voxels
Date: 26 May 2003 06:45:01
Message: <web.3ed1eef81187fffdda05be620@news.povray.org>
Christopher James Huff wrote:

>You want to render a POV scene to a voxel field? This can not be done
>directly, but there are several ways you could approach it. You could
>put the objects to be rendered in the voxel field into a union and
>intersect them with a pair of planes to get a "slice" of the scene, you
>could then render several frames with the planes progressing along the
>object, and combine the frames into a final voxel field for display.

I have  already considered this but I think I will be unable to get a good
lighting that way.

>This all requires a lot of manual modifications to the scene, though,
>and it sounds like you want some kind of patch that gives voxel output.
>This is an interesting idea, and I can think of a couple possible
>methods. I'm not clear on how much lighting calculations you want to do
>immediately or how realistic your voxel rendering is to be.

I would like to voxelize the scene with a global lighting applied. I do not
intend to do any lighting in real time (maybe later I will think about some
reflection/refraction).

>One possibility is to march through the lattice of voxels covering the
>scene, and for each voxel compute the average of the pigments for each
>object that contains that point. This will lose any infinitely thin
>objects, for those you would need to use raytracing. By collecting the
>pigment information and saving light source information to a file for
>your voxel renderer, you could get a shaded color view of the scene.

This method would probably too slow for the size of voxel I want, but thanks
for the idea.
My idea is the one Ben described, I just want some code hints from those who
know the sources.
Could you ( or anybody) point me (in general terms) what are the steps to
find all the crossings of a ray with the scene in a known range? I am
currenlty looking at the trace function un render.cpp.

>BTW, what format are you using? I've been working on an extended density
>file format for my own experimentation, maybe you would find it
>interesting.

About the format, I just want to store a final color for the voxel.  I will
crunch the result in a variation of the octree I have thinked. I will try
to crunch the voxel by identifying similar sections, although this is going
to be quite slow...What have you thinked? I know several voxel formats
myself; some are much faster for rendering, but waste too much memory...

>If you are using the GUI version, you may want to look into MacMegaPOV,
>which has a GUI that works better under OS X than the official version.
>The command line version can be compiled for OS X, but it involves some
>makefile hacking. It would probably be easiest to install it through
>Fink. All this only applies if you are not making your own patch...if
>you are patching, the path of least resistance would be to compile the
>command line version using the free development tools.

I have it installed through Fink, but I am going to test "MacMegaPOV"; for
some reason I prefer GUIs to commandlines...


Post a reply to this message

From: Christopher James Huff
Subject: Re: Using POV to render voxels
Date: 28 May 2003 22:28:00
Message: <cjameshuff-2307CF.21292528052003@netplex.aussie.org>
In article <web.3ed1eef81187fffdda05be620@news.povray.org>,
 "Peskanov" <nomail@nomail> wrote:

> >You want to render a POV scene to a voxel field? This can not be done
> >directly, but there are several ways you could approach it. You could
> >put the objects to be rendered in the voxel field into a union and
> >intersect them with a pair of planes to get a "slice" of the scene, you
> >could then render several frames with the planes progressing along the
> >object, and combine the frames into a final voxel field for display.
> 
> I have  already considered this but I think I will be unable to get a good
> lighting that way.

Good lighting? What kind of lighting do you expect?


> I would like to voxelize the scene with a global lighting applied. I do not
> intend to do any lighting in real time (maybe later I will think about some
> reflection/refraction).

Highlights and some other effects are also dependant on the direction of 
the incoming ray. More importantly, POV-Ray's global illumination is 
viewpoint-dependant.


> This method would probably too slow for the size of voxel I want, but thanks
> for the idea.

It would also be helpful if you mentioned what voxelfield resolutions 
you are thinking of. Unless you are using really fine-grained voxel 
fields, it could easily be faster...insideness calculations are usually 
a lot easier than intersection calculations.


> Could you ( or anybody) point me (in general terms) what are the steps to
> find all the crossings of a ray with the scene in a known range? I am
> currenlty looking at the trace function un render.cpp.

Trace() in render.cpp is probably the best place to start. Change it to 
accumulate all the intersections and figure out some way to translate 
that intersection list to a line of voxels and you have a good start. 
But as I mentioned, the results will be dependant on the direction of 
the incoming ray, so you may not get what you expect. You might have to 
disable quite a few effects when generating the voxel field.


> About the format, I just want to store a final color for the voxel.  I will
> crunch the result in a variation of the octree I have thinked. I will try
> to crunch the voxel by identifying similar sections, although this is going
> to be quite slow...What have you thinked? I know several voxel formats

You mean generating an oct-tree with large blocks covering multiple 
voxels with very similar values? Sort of like dividing an image into a 
heirarchy of flat-colored rectangles? I've thought about this as well, 
but I don't know how well it would work...maybe a simple run-length 
encoding would be more efficient, it would certainly be easier to read 
and write. I've considered using (or abusing?) animation file formats, 
maybe MNG (http://www.libpng.org/pub/mng/), but for now I have just been 
planning on using gzip to compress the data. Another idea I've been 
working on is a procedural format...basically a simple bytecode 
interpreter that can generate voxel fields of arbitrary resolution at 
runtime, sort of like PostScript or other vector image formats.


> myself; some are much faster for rendering, but waste too much memory...

What does the file format have to do with rendering speed? I'm assuming 
this is real-time display, so reading the file during rendering is not a 
good idea.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/


Post a reply to this message

From: Peskanov
Subject: Re: Using POV to render voxels
Date: 29 May 2003 19:00:02
Message: <web.3ed68f3b1187fffdda05be620@news.povray.org>
Christopher James Huff wrote:

>Good lighting? What kind of lighting do you expect?

Global lighting (sun), with shadows, would be enough.

>Highlights and some other effects are also dependant on the direction of
>the incoming ray. More importantly, POV-Ray's global illumination is
>viewpoint-dependant.

Then I will try to calculate the lightings using a different vector. One ray
to get the crosses, other ray to get the lights, what do you think?

>It would also be helpful if you mentioned what voxelfield resolutions
>you are thinking of. Unless you are using really fine-grained voxel
>fields, it could easily be faster...insideness calculations are usually
>a lot easier than intersection calculations.

Which functions are used to get pigment from a coodinate?

I am using big resolution voxels, 12 bits side (4096*4096*4096).
Mind that I am not interested in the interiors of closed objects. My
objective is not showing "slices", but to show very complex scenes (nature
scenes, for example).

>Trace() in render.cpp is probably the best place to start. Change it to
>accumulate all the intersections and figure out some way to translate
>that intersection list to a line of voxels and you have a good start.
>But as I mentioned, the results will be dependant on the direction of
>the incoming ray, so you may not get what you expect. You might have to
>disable quite a few effects when generating the voxel field.

Ok, thanks.

>You mean generating an oct-tree with large blocks covering multiple
>voxels with very similar values? Sort of like dividing an image into a
>heirarchy of flat-colored rectangles? I've thought about this as well,
>but I don't know how well it would work..

Yes, that's the idea; I think it will work ok for synthetic scenes like POV
ones. These use to have lots of patterns...Also, I can graduate the
"matching" factor.

>.maybe a simple run-length
>encoding would be more efficient, it would certainly be easier to read
>and write. I've considered using (or abusing?) animation file formats,
>maybe MNG (http://www.libpng.org/pub/mng/), but for now I have just been
>planning on using gzip to compress the data. Another idea I've been
>working on is a procedural format...basically a simple bytecode
>interpreter that can generate voxel fields of arbitrary resolution at
>runtime, sort of like PostScript or other vector image formats.

If you aim is to compress the data as much as you can, and the voxel data is
really volumetric (like tomography), 3D wavelets should be your best shot.
I think that encoding voxels as the most simple wavelets and using a general
block sorting compressor with big buffers (bzip2 -9 for example) should
give very good results. Repetition is very strong in voxels, but sometimes
the copies are too far for common compressors.
My interest is to voxelize only the "skins" of the objects, so I guess our
targets are different.

>What does the file format have to do with rendering speed? I'm assuming
>this is real-time display, so reading the file during rendering is not a
>good idea.

No, the format is for real time. As I am telling you, the resolution of the
voxel is big. This means I can't store it in memory uncompressed, and also
rendering would be muuuuuch slower.


Post a reply to this message

From: Christopher James Huff
Subject: Re: Using POV to render voxels
Date: 29 May 2003 22:32:35
Message: <cjameshuff-A09F0D.21340429052003@netplex.aussie.org>
In article <web.3ed68f3b1187fffdda05be620@news.povray.org>,
 "Peskanov" <nomail@nomail> wrote:

> >Good lighting? What kind of lighting do you expect?
> 
> Global lighting (sun), with shadows, would be enough.

This may be a problem then. POV radiosity is dependant on camera 
location, and you won't have a camera.


> >Highlights and some other effects are also dependant on the direction of
> >the incoming ray. More importantly, POV-Ray's global illumination is
> >viewpoint-dependant.
> 
> Then I will try to calculate the lightings using a different vector. One ray
> to get the crosses, other ray to get the lights, what do you think?

I don't know what you expect to get from this, you will still be 
computing the lighting from a single direction. The basic problem is 
this: you are storing color data, and the colors depend on the viewing 
direction, which is just not available at the time you are generating 
the voxels. You simply won't have any highlights, reflection, 
refraction, iridescence, or whatever else is dependant on viewing 
direction unless you save this information as well and build a renderer 
to do it.

You could generate multiple voxel fields from different viewpoints and 
interpolate, but this would greatly increase file size and memory usage.


> >It would also be helpful if you mentioned what voxelfield resolutions
> >you are thinking of. Unless you are using really fine-grained voxel
> >fields, it could easily be faster...insideness calculations are usually
> >a lot easier than intersection calculations.
> 
> Which functions are used to get pigment from a coodinate?

You don't. A point is not enough information, you need the intersection 
and ray as well. The function is Determine_Apparent_Colour(), which is 
implemented in lighting.cpp.


> I am using big resolution voxels, 12 bits side (4096*4096*4096).
> Mind that I am not interested in the interiors of closed objects. My
> objective is not showing "slices", but to show very complex scenes (nature
> scenes, for example).

A full field would be 192GB at 24 bit/voxel, so I take it you're talking 
about some sort of "sparse" voxel field, storing only the voxels that 
are on the surface of an object...unless I goofed with the math, as long 
as less than 40% of the available voxels are used, the file size will be 
smaller. Given the large amounts of empty space in most scenes, this 
should be quite a bit more efficient. You are also likely to end up with 
long lines of voxels, RLE may still come in useful here...it might be 
interesting to try to figure out a way to have runs along each axis.


> If you aim is to compress the data as much as you can, and the voxel data is
> really volumetric (like tomography), 3D wavelets should be your best shot.
> I think that encoding voxels as the most simple wavelets and using a general
> block sorting compressor with big buffers (bzip2 -9 for example) should
> give very good results. Repetition is very strong in voxels, but sometimes
> the copies are too far for common compressors.

Yes, I've heard of people doing work on wavelet compression of voxels, 
but that goes beyond anything I plan to implement.


> No, the format is for real time. As I am telling you, the resolution of the
> voxel is big. This means I can't store it in memory uncompressed, and also
> rendering would be muuuuuch slower.

You're saying you plan on reading and decoding the voxel file for every 
frame in real-time? That sounds...unlikely. Are you planning on somehow 
keeping only the visible voxels in RAM, discarding hidden ones and 
loading newly visible ones as the viewpoint changes? My first thought is 
that all that "housekeeping" would slow things even further, though I 
could be wrong.

BTW, something fairly similar that I've also been looking at is point 
field geometry...basically an alternative to triangle/polygon meshes 
where you store a bunch of points on the object surface. It can even be 
raytraced directly:
http://graphics.lcs.mit.edu/~gs/papers/psp/

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.