Chris Huff wrote:
> 
[...]
> 
> *Lots* of ram...since a 3df file is simply 256-bit grayscale, you would
> need separate 3df files to specify those other variables. And to get a
> large landscape, you would need a fairly high-res landscape file(the
> others, like erodability maps, could be much lower resolution).
> A 256*64*256 file would equal 4MB...3df doesn't have any compression.
> And 512*128*512 would be 32MB. Good thing interpolation is available. :-)
> 

All that is not really effective, because you have to carry the whole "air"
around that is never used.  

Christoph

--
Christoph Hormann <chr### [at] gmxde>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <8F7CC6C2Fseed7@204.213.191.228>, ing### [at] homenl (ingo) 
wrote:

> Could you "abuse" animated png's (mng) for that?

You could...but the file size would probably be bigger than it needs to 
be, unless mng supports 256-shade grayscale. And how does it handle the 
compression? Are frames compressed individually and stacked together, or 
does the compression use info from previous and following frames?


> Also you can stuff more than one image in a single tga (rl encoded) or 
> tiff file.

I know about these "stacks", but I don't think the compression is as 
efficient as it could be.

It might be better to have a custom format which can handle no 
compression, lossless compression, lossy compression(like MPEG), 8-bit 
grayscale and 24-bit color. Maybe we could call it 3df. :-)
Or maybe you could just support several animation formats, including MNG 
and MPEG.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

In article <chrishuff-12226F.11302925072000@news.povray.org>, Chris 
Huff <chr### [at] maccom> wrote:

> since a 3df file is simply 256-bit grayscale...

I meant 256-shade grayscale, of course. As in 8-bit grayscale. :-)

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

In article <397DD493.909A1DC0@schunter.etc.tu-bs.de>, 
chr### [at] gmxde wrote:

> All that is not really effective, because you have to carry the whole 
> "air" around that is never used.  

I'm not sure what you mean...even though it isn't used, you still have 
to store it. The "air" is simply any voxel with a density of 0, you have 
to store these voxels along with all the others.
An alternative would be to store the coordinates, size, and density of 
each voxel. For some files, this would be smaller...but for others, it 
would be a lot larger.
A compromise might be to partition the file into cubical chunks, each 
one with it's own resolution. That way, large areas of a single value 
could be represented as a single voxel, while areas with a lot of 
small-scale changes could still be accurately represented. There are 
probably better ways to compress the data, though...

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Chris Huff wrote:
> 
> I'm not sure what you mean...even though it isn't used, you still have
> to store it. The "air" is simply any voxel with a density of 0, you have
> to store these voxels along with all the others.

That's what i meant.

> An alternative would be to store the coordinates, size, and density of
> each voxel. For some files, this would be smaller...but for others, it
> would be a lot larger.

I thought of storing the data in form of "columns" of variable height, but
that's probably very slow and not that easy to handle.  Could save a lot of
memory when working with high vertical resolution. 

> A compromise might be to partition the file into cubical chunks, each
> one with it's own resolution. That way, large areas of a single value
> could be represented as a single voxel, while areas with a lot of
> small-scale changes could still be accurately represented. There are
> probably better ways to compress the data, though...
> 

Sounds much like wavelet-compression, that should also work with 3 dimensions,
but it's probably quite calculation intensive.  

Christoph

--
Christoph Hormann <chr### [at] gmxde>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Chris Huff wrote:

>In article <8F7CC6C2Fseed7@204.213.191.228>, ing### [at] homenl (ingo) 
>wrote:
>
>> Could you "abuse" animated png's (mng) for that?
>
>You could...but the file size would probably be bigger than it needs to 
>be, unless mng supports 256-shade grayscale. And how does it handle the 
>compression? Are frames compressed individually and stacked together, or 
>does the compression use info from previous and following frames?

Sorry, only a link to answer your questions http://www.libpng.org/pub/mng/
I made a 256 colour mng, it was smaller than the animated gif.


Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

In article <397DDEF9.7680CA04@schunter.etc.tu-bs.de>, 
chr### [at] gmxde wrote:

> I thought of storing the data in form of "columns" of variable 
> height, but that's probably very slow and not that easy to handle.  
> Could save a lot of memory when working with high vertical 
> resolution. 

Though not the most efficient method, and mainly useful for 
height-field-like voxel structures, that should be quite possible...


> Sounds much like wavelet-compression, that should also work with 3 
> dimensions, but it's probably quite calculation intensive.  

I don't think this is anything like wavelet compression, which I think 
is based on fourier transforms. I think this would have more in common 
with run-length encoding. Basically, divide the voxel data up into 
cubes. If the voxels in a cube vary by less than a certain amount, the 
resolution within that cube is reduced or the voxels are replaced with a 
single, larger voxel. If more than that amount, all of the data is 
retained, or maybe the cube gets subdivided.
This would definitely be more computationally expensive than 
uncompressed files or your "column" encoding, but could be quite 
efficient for many structures.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

My (perhaps self-limiting) philosophy is:  why use a paint program when you
can use a vector one, why use a vector program when you can do 3d, why use
a heightfield when you can use an isosurface.  The work need not be
re-created from scratch if another point of view or higher resolution is
required.


Chris Huff wrote:

> In article <397DA95A.B58E927B@my-dejanews.com>,
> gre### [at] my-dejanewscom wrote:
>
> > Ugh, that would require me understanding what the heck a 3df is.
>
> Yes...I suppose it would.
> A 3df is a 3D Density File, sort of a 3D bitmap.(which I guess would
> make POV a 3D vector format) Instead of storing polygons or other
> shapes, it stores voxels, the 3D equivalent of a pixel.
> POV has the ability to read these files as a pattern, so you can use
> them as input for an isosurface. It also has interpolation features
> which make lower-resolution 3df files useable.

Post a reply to this message

In article <397EF8DB.340374FD@my-dejanews.com>, 
gre### [at] my-dejanewscom wrote:

> My (perhaps self-limiting) philosophy is:  why use a paint program 
> when you can use a vector one, why use a vector program when you can 
> do 3d, why use a heightfield when you can use an isosurface.  The 
> work need not be re-created from scratch if another point of view or 
> higher resolution is required.

Mostly I agree, and df3's are even less useful with the blob pattern 
available(though sometimes considerably more compact). However, they do 
have certain uses, such as the ability to edit specific voxels, 
possibilities for external modellers, being a useful format for certain 
kinds of data that can't easily be converted to a "vector" format(like 
certain volumetric data, MRI scans, etc), the ability to apply filters 
to the data, etc.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

And I guess NASA is too lazy to post the isosurface equations for
Mars.............

Chris Huff wrote:

> Mostly I agree, and df3's are even less useful with the blob pattern
> available(though sometimes considerably more compact). However, they do
> have certain uses, such as the ability to edit specific voxels,
> possibilities for external modellers, being a useful format for certain
> kinds of data that can't easily be converted to a "vector" format(like
> certain volumetric data, MRI scans, etc), the ability to apply filters
> to the data, etc.

Post a reply to this message