 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi all!
This is just a quick shot, haven't done that much research into it yet, but
I was wondering if anyone has already attempted it and could give me some
advice. The df3 files POV-Ray may read are pretty straightforward, and I
wondered if there may be a way to use Java to write a df3-file.
As I understand it, df3 isn't plain-text, but byte-code, so I'm actually
more or less asking how I can use Java to not write plain-text, but rather
byte-code to disk, or how I can convert doubles/floats/int/etc to byte and
then save that.
Any help, be it pointers, tutorials or just a plain "Can't be done." is
appreciated.
Regards,
Tim
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40268211$1@news.povray.org>,
"Tim Nikias v2.0" <tim.nikias (@) nolights.de> wrote:
> As I understand it, df3 isn't plain-text, but byte-code, so I'm actually
> more or less asking how I can use Java to not write plain-text, but rather
> byte-code to disk, or how I can convert doubles/floats/int/etc to byte and
> then save that.
DF3 files are binary, as opposed to text. The term "byte-code" isn't a
file type, it refers to the numeric machine codes that languages like
Java are compiled to, which is then run by the virtual machine. It has
absolutely nothing to do with the DF3 format. And yes, Java is capable
of generating DF3 files, but I'd be concerned about how well its garbage
collector can cope with the memory use required.
Typical density files use one-byte integers for the density values. You
just have to convert from whatever density range you're using to the
0-255 range possible to store in a single byte.
--
Christopher James Huff <cja### [at] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> DF3 files are binary, as opposed to text.
Ups, should have phrased that better. I do know the difference of course.
But I won't go on about how I'm fighting with the flu and having a headache
hinders me from some plain thoughts... Ups again, just did that. ;-)
> Typical density files use one-byte integers for the density values. You
> just have to convert from whatever density range you're using to the
> 0-255 range possible to store in a single byte.
That's the tricky bit: the conversion. I don't know the commands/libraries
I'd have to use with Java to convert float/double to bytes, and then again
which commands/libraries I'd have to use to write them to disk. I'll go
around searching once I actually attempt a df3 stunt, but I thought maybe
someone has had experience with that already, so I asked.
Is it possible to use more than just a single byte? Or would I be getting
myself into trouble (file format-wise) with that?
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4026a96c$1@news.povray.org>,
"Tim Nikias v2.0" <tim.nikias (@) nolights.de> wrote:
> That's the tricky bit: the conversion. I don't know the commands/libraries
> I'd have to use with Java to convert float/double to bytes, and then again
> which commands/libraries I'd have to use to write them to disk. I'll go
> around searching once I actually attempt a df3 stunt, but I thought maybe
> someone has had experience with that already, so I asked.
The Java I/O classes have methods for writing binary data byte-by-byte.
If you have floating point data with a range of [0, 1], just multiply it
by 255 and convert to a byte, and write that byte value.
> Is it possible to use more than just a single byte? Or would I be getting
> myself into trouble (file format-wise) with that?
No, it is not, no more possible than it is to put 16 bit values in an
8-bit component of any image format. The entire file has to be 8, 16, or
24 bit.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
[some information about Java-IOand how df3 may only be single-byte per
voxel]
Thanks for the information. I'll see what I can cook up with that once I get
the time.
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.
Regards,
Tim
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Burn? It's a file, not a CD...
Wrong term, I should have used "baked". In CGI, that's taking simulated data
and writing it to disk, e.g. shadowmaps from Global Illumination simulations
etc.
> 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.
That's what I was after.
> A related topic: I've been playing around with the idea of an extended
> density file format (called, imaginatively enough, EDF). SNIP
Sounds interesting. I guess the technique you might be using is somewhat
related to the different image-formats to reduce the amount of data. From
that perspective, the DF3 we use now might be considered a Bitmap, where
you're going for PNG. Well, PNG might not be it, since it saves the used
colors beforeend... But you get the idea, I hope.
I think that your EDF might be a good development for POV-Ray, since it'd
make larger Density-Files possible whilst using less disk-/RAM-space. So, by
all means, go ahead and do it! :-)
Regards,
Tim
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4027324f@news.povray.org>,
"Tim Nikias v2.0" <tim.nikias (@) nolights.de> wrote:
> > A related topic: I've been playing around with the idea of an extended
> > density file format (called, imaginatively enough, EDF). SNIP
>
> Sounds interesting. I guess the technique you might be using is somewhat
> related to the different image-formats to reduce the amount of data. From
> that perspective, the DF3 we use now might be considered a Bitmap, where
> you're going for PNG. Well, PNG might not be it, since it saves the used
> colors beforeend... But you get the idea, I hope.
No...as I said, the voxel version is simply a DF3 file with some
additional headers identifying it as a DF3 file. It will eventually
support some kind of compression, but not immediately. The "sparse"
formats aren't compressed, they just store only the non-0 points. The
overhead of doing so will make the files bigger if more than a certain
percentage of the file is non-0 density. And the procedural version
isn't compressed either, it is analogous to a vector format.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:40268211$1@news.povray.org Tim Nikias v2.0 wrote:
>[...] there may be a way to use Java to write a df3-file.
Here is a java program plus ource to manipulate voxel datasets, maybe it
can inspire you:
http://bij.isi.uu.nl/index.htm
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Here is a java program plus ource to manipulate voxel datasets, maybe it
> can inspire you:
>
> http://bij.isi.uu.nl/index.htm
I'll have to look through the code though to figure out if I can make any
sense of it to apply the newly gained knowledge, but thanks anyway! At least
something to base some studies on! :-)
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
