 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>
> In article <8F9DE3567seed7@204.213.191.228>, ing### [at] home nl (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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp wrote:
>
> "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.
Thanks but this
It starts with an array 0..257 by 0..257 with all the pairs
containing 0 and 257 (the edges, boundary values) constrained to
zero.
Step 1. Each of the other array elements, 1..128,1..128 are given
a random number between -0.5 and +0.5.
Step 2. Then each cell is averaged with its nearest neighbors (8
neighbors + itself for 9).
Step 3. Return to step 1, twenty times in the case of the
attached image.
Step 4. convert the final array of numbers into triangles in mesh
object format.
Setp 5. Render
is the original process.
Step 4 is now converting to a TARGA image. I stick the numbers into the
TARGA and the POV takes them right back out. It just made sense for POV
to read a file with the format of [length, width, ... l*w values ... ]
for a z(x,y) representation of a HEIGHT_FIELD.
Faking a .tga image is an unnecessary step.
--
Q. "Do you realize I can defame you without penalty?"
A, "Do you realize I can let you?"
-- The Iron Webmaster, 31
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 27 Aug 2000 16:00:38 -0400, matt giwer wrote:
> 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?
There is a format to read it more-or-less directly: PPM format. On a Unix
box, try `man 5 ppm'
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>
> On Sun, 27 Aug 2000 16:00:38 -0400, matt giwer wrote:
> > 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?
>
> There is a format to read it more-or-less directly: PPM format. On a Unix
> box, try `man 5 ppm'
I've looked at that. Thanks by not an issue. I have no problem now.
Using an image is a compact data format.
I am suggesting a format alternative to an image file. This would be a
very simple data storage format, length, width, data. Single byte is
good enough for visualization. Lo hi byte data would be icing.
--
Every great journey starts with a single step
into a very large pothole.
-- The Iron Webmaster, 36
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 28 Aug 2000 22:24:28 -0400, matt giwer wrote:
> I am suggesting a format alternative to an image file. This would be a
>very simple data storage format, length, width, data. Single byte is
>good enough for visualization. Lo hi byte data would be icing.
That's what PPM is.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>
> On Mon, 28 Aug 2000 22:24:28 -0400, matt giwer wrote:
> > I am suggesting a format alternative to an image file. This would be a
> >very simple data storage format, length, width, data. Single byte is
> >good enough for visualization. Lo hi byte data would be icing.
>
> That's what PPM is.
No, it is decimal (three bytes or five bytes if it does 64k levels) and
whitespace delimited meaning an extra byte so either 4 or 6 per pixel.
TARGA at 256 grey levels is one byte per pixel.
As I have said elsewhere, I need to do an animation as the ultimate and
given infinite disk space those differences are minor.
--
Vote for Senator Kelly http://www.mutantwatch.com/
Paid for by the Kelly2000 campaign committee
-- The Iron Webmaster, 19
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
