 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp wrote:
>
> "matt giwer" <jul### [at] ij net> 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
|
|
| |
| |
|
|
|
|
| |
