In article <4026b909@news.povray.org>,
 "Tim Nikias v2.0" <tim.nikias (@) nolights.de> wrote:

> [some information about Java-IOand how df3 may only be single-byte per
> voxel]

In 3.6, they may also be 16 or 32 bit, but it's still restricted to the 
same bit depth for all voxels.


> A few weeks (or maybe months) ago, there had been a thread about df3 and if
> POV-Ray couldn't "burn" df3 files from an object. An idea I had was to write
> a POV-Script which would sample the voxels and write the densities to disk
> (which would be more or less 0 or 1 values). A Java-Application could read
> the data and convert it to df3 for faster usage within POV. Though the
> sampling inside POV would be slow, the resulting file-conversion would speed
> things up for later usage.

Burn? It's a file, not a CD...
POV-Ray file I/O doesn't support binary output, making things like this 
quite difficult. However, you could output in some intermediate form, 
and process the generated file into a useable DF3 file. 

A related topic: I've been playing around with the idea of an extended 
density file format (called, imaginatively enough, EDF). It would 
support voxel type data like the DF3 formats, only with color data as 
well, and would also support "sparse" voxel data where only the non-0 
voxels are stored, and procedural density files which would basically 
consist of bytecode run by an interpreter to get the density at a point. 
The filled voxel formats would be no harder to read or write than DF3 
files, being basically DF3 files with some extra fields identifying the 
file type.

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