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