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