I haven't been reading here in months so perhaps I am being repetative. 

	How about a type that is not image related? 

	It would be specified simply by 

	height_field {
		RAW { length, width, point 1, point 2, ...} 
	}

	Reason: (See 'concept to visualization' and '... II' in binaries) This
is related to visualizing z(x,y). 

	I first implemented a visualization with a mesh save that generated 19M
data files, took forever and would crash a linux graphics terminal. 

	It was suggested I use a height field so I had to hack an image file
format. 

	Why should I or anyone have to hack an image file format? Not having
stared at the source files I assume all it is doing is extracting the
above data in the first place. Why not simply a format to read it
directly? 

	POV is directly an aid to visualization of molecules in chemistry. This
can make POV a direct aid to the visualization of math in science and
engineering without the need to do image file hacks. 

-- 
Remember, if the conspiracy isn't vast
it isn't right wing.
	-- The Iron Webmaster, 55

Post a reply to this message

In article <39A97366.15742219@ij.net>, matt giwer <jul### [at] ijnet> 
wrote:

> 	I haven't been reading here in months so perhaps I am being repetative. 
> 
> 	How about a type that is not image related? 
> 
> 	It would be specified simply by 
> 
> 	height_field {
> 		RAW { length, width, point 1, point 2, ...} 
> 	}
...snip...

I think a better solution would be to just add a new image type, so you 
wouldn't be limited to height fields, but could use it in media density, 
image/texture maps, isosurfaces, etc. It is a good suggestion, though. 
Some of the image formats useable by POV are very simple though...some 
only slightly more complex than this.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

matt giwer wrote:
> 
>         I haven't been reading here in months so perhaps I am being repetative.
> 
>         How about a type that is not image related?
> 
>         It would be specified simply by
> 
>         height_field {
>                 RAW { length, width, point 1, point 2, ...}
>         }
> 

Looks nearly identical to a pgm file, but what format did you intend for the
"point1, ..." ?

IMO, the advantage of Image files for this purpose is mainly the small filesize
and fast parsing due to binary format, and the possibility to edit them in
regular image manipulation programs.  

Your idea is surely quite interesting for small heightfields, but in most cases
I would prefer an image file format.  You can always use pgm, if you want an
ascii file.  

Christoph

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

Post a reply to this message

Chris Huff wrote:

>I think a better solution would be to just add a new image type, so you 
>wouldn't be limited to height fields, but could use it in media density, 
>image/texture maps, isosurfaces, etc. It is a good suggestion, though. 
>Some of the image formats useable by POV are very simple though...some 
>only slightly more complex than this.
>

How different would it be from the "i_dat3d" library with data_2d_1 or 
data_2d_3, if at all ?


Ingo

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

Post a reply to this message

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

> How different would it be from the "i_dat3d" library with data_2d_1 or 
> data_2d_3, if at all ?

There would be very little difference...actually, I think this and other 
3D voxel formats would be useful additions to the readable file formats. 
If they could be used in pigments, it would eliminate the need for 
specialized isosurface functions and provide more flexible textureing 
options.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote:
> 
> In article <8F9DE3567seed7@204.213.191.228>, ing### [at] homenl (ingo)
> wrote:
> 
> > How different would it be from the "i_dat3d" library with data_2d_1 or
> > data_2d_3, if at all ?
> 
> There would be very little difference...actually, I think this and other
> 3D voxel formats would be useful additions to the readable file formats.
> If they could be used in pigments, it would eliminate the need for
> specialized isosurface functions and provide more flexible textureing
> options.
> 

If i understand things right they can be used in pigments although i never tried
it.  

BTW, what's the difference between the 'i_dat3d' stuff and a density_file /
image_map pigment function except the syntax ? maybe speed ? I just saw that you
can also use df3 files for those functions and found everything quite
irritating.  

Christoph

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

Post a reply to this message

In article <39A983CE.351F4573@schunter.etc.tu-bs.de>, 
chr### [at] gmxde wrote:

> If i understand things right they can be used in pigments although i 
> never tried it.  

They can be used as function patterns in a pigment, but I don't think 
they can be used directly in a pigment.


> BTW, what's the difference between the 'i_dat3d' stuff and a 
> density_file / image_map pigment function except the syntax ? maybe 
> speed ? I just saw that you can also use df3 files for those 
> functions and found everything quite irritating.  

I think the i_dat3d format allows for colors, while df3 only stores 
8-bit grayscale. And the i_dat3d *function* can read df3 files, but not 
the other way around.
If a 3D image map was allowed, it would solve some of the problems with 
mapping image maps without obvious stretching, tiling, or deformations. 
The memory use would skyrocket, though...3D bitmaps are big. And there 
currently doesn't seem to be much software that supports them, though I 
plan to write a couple Mac programs...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Christoph Hormann wrote:
> 
> matt giwer wrote:
> >
> >         I haven't been reading here in months so perhaps I am being repetative.
> >
> >         How about a type that is not image related?
> >
> >         It would be specified simply by
> >
> >         height_field {
> >                 RAW { length, width, point 1, point 2, ...}
> >         }
> >
> 
> Looks nearly identical to a pgm file, but what format did you intend for the
> "point1, ..." ? 

	Whatever makes the POV team programmers happy. Any user who can write a
program to create the file can do any scaling required. I'd guess 0-255
would be the least effort since that is most commonly what it being
extracted from image files. 64k would be desirable but since this is for
visualization not measurement I don't see a pressing need for it. 

> IMO, the advantage of Image files for this purpose is mainly the small filesize
> and fast parsing due to binary format, and the possibility to edit them in
> regular image manipulation programs.

	It could also be an external data file RAW "filename.ext" 

> Your idea is surely quite interesting for small heightfields, but in most cases
> I would prefer an image file format.  You can always use pgm, if you want an
> ascii file.

	What I find I have to do is the intermediary step of creating the image
file for POV so that POV can take the same numbers right back out of it. 

	As for size, in my first attempt at this, it is 257x257 + 60 for the
TARGA format. The time is trivial on a PII/300. 

-- 
"I'm going to find that damned butterfly and kill it." 
Attributed to a Florida resident after hurricane Andrew.
	--	The Iron Webmaster, 50

Post a reply to this message

Chris Huff wrote:
> 
> > If i understand things right they can be used in pigments although i 
> > never tried it. 
> 
> They can be used as function patterns in a pigment, but I don't think
> they can be used directly in a pigment.
> 

That's what i meant.

> > BTW, what's the difference between the 'i_dat3d' stuff and a
> > density_file / image_map pigment function except the syntax ? maybe
> > speed ? I just saw that you can also use df3 files for those
> > functions and found everything quite irritating.
> 
> I think the i_dat3d format allows for colors, while df3 only stores
> 8-bit grayscale. And the i_dat3d *function* can read df3 files, but not
> the other way around.
> If a 3D image map was allowed, it would solve some of the problems with
> mapping image maps without obvious stretching, tiling, or deformations.
> The memory use would skyrocket, though...3D bitmaps are big. And there
> currently doesn't seem to be much software that supports them, though I
> plan to write a couple Mac programs...
> 

I agree, the color aspect really seems quite useful.

Christoph

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

Post a reply to this message

"matt giwer" <jul### [at] ijnet> wrote...
> I first implemented a visualization with a mesh save that generated 19M
> data files, took forever and would crash a linux graphics terminal.

You could try using MegaPov's mesh2 - it uses less space to store the same
data.

> Why should I or anyone have to hack an image file format? Not having
> stared at the source files I assume all it is doing is extracting the
> above data in the first place. Why not simply a format to read it
> directly?

If you're getting your data from some sort of pattern (such as an
iso-function), then you could use the "pattern" image type in MegaPov.  It
will generate image data internally from a pigment.

You could also use the iso-function directly in an isosurface, though the
render time may be slower that way.

-Nathan

Post a reply to this message