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