Hi!
I am trying to use povray to generate a 3d surface from a big matrix of real
numbers, which are the output of my program. I read a lot of things about
povray, the documentation, etc, but i really don't know how i can do it.
Everthing i need is a light_source, a camera and this surface. Nothing more.
Somebody may help me to make a simple .pov file, which my program will
generate, only changing the parameters?
(ps: if i did any mistake in my english, i'm sorry in advance!)

Thanks

ps:
Examples:
matrix file:
http://www.ic.unicamp.br/~ra015988/lis/artigos/novo/superficie.dat
(the sintax of this file may change as need)
the target file, i made it in 3dmax
http://www.ic.unicamp.br/~ra015988/lis/artigos/novo/superficie_saltoe.png

Post a reply to this message

<fab### [at] icunicampbr> did spake, saying:

> Hi!
> I am trying to use povray to generate a 3d surface from a big matrix of  
> real
> numbers, which are the output of my program. I read a lot of things about
> povray, the documentation, etc, but i really don't know how i can do it.
> Everthing i need is a light_source, a camera and this surface. Nothing  
> more.
> Somebody may help me to make a simple .pov file, which my program will
> generate, only changing the parameters?
> (ps: if i did any mistake in my english, i'm sorry in advance!)
>
> Thanks

> ps:
> Examples:
> matrix file:
> http://www.ic.unicamp.br/~ra015988/lis/artigos/novo/superficie.dat
> (the sintax of this file may change as need)
> the target file, i made it in 3dmax
> http://www.ic.unicamp.br/~ra015988/lis/artigos/novo/superficie_saltoe.png

To get povray to read your superficie.dat file you need to add commas  
instead of spaces like:

0,0,1,
0,1,3,
0,2,0,
0,3,0,

Then try:

//start code

/*
Assume first value read is row(Z)
second value column (X)
third value height {Y)
*/

#fopen MyFile "superficie.dat" read
#while (defined(MyFile))
#read (MyFile,LastZ, LastX, DitchY)
#end
/*
The last values read should be the highest needed
DitchY is not needed to be kept
*/

/*
Remember to count the 0
*/

#declare LastZ=LastZ+1;
#declare LastX=LastX+1;

camera{
location <LastX/2,100,-100>
look_at  <LastX/2,0,LastZ/2>
}

light_source{<LastX/2,50,LastZ/2> rgb 1}

#declare MyArray= array[LastZ][LastX];

/*
Read the file again and put the values into an array
*/

#fopen MyFile "superficie.dat" read
#while (defined(MyFile))
#read (MyFile,MyZ, MyX, MyY)
#declare MyArray[MyZ][MyX]=MyY;
#end

#declare i=0;
#declare j=0;

/*
Draw a box of correct height and move it to the correct place
as the column(X) and row(Z) are the same as i and j use these to
translate the box
*/

#while(i<LastZ)

#while(j<LastX)
box{0,<1,MyArray[i][j],1> translate <j,0,i> pigment{rgb 1}}
#declare j=j+1;
#end

#declare i=i+1;
#declare j=0;
#end
//end code

Uses boxes rather than points and might be slow with a *lot* of data (this  
took 26 sec on my computer, 76800 objects) but I hope it helps.

--
Phil Cook

-- 
All thoughts and comments are my own unless otherwise stated and I am  
happy to be proven wrong.

Post a reply to this message

And lo on Thu, 24 Jun 2004 15:46:27 +0100, Phil Cook  
<phi### [at] nospamdeckingdealscouk> did spake, saying:


> <fab### [at] icunicampbr> did spake, saying:
>

Checking against the picture you linked to, my code seems to produce a  
upside-down mirror of your image. Use this instead:

//start code
#fopen MyFile "superficie.dat" read
#while (defined(MyFile))
#read (MyFile,LastX, LastZ, DitchY)
#end

#declare LastX=LastX+1;
#declare LastZ=LastZ+1;

camera{
location <-LastX/2,300,-300>
look_at  <-LastX/2,0,-LastZ/2>
}

light_source{<-LastX/2,50,-LastZ/2> rgb 1 shadowless}

#declare MyArray= array[LastX][LastZ];

#fopen MyFile "superficie.dat" read
#while (defined(MyFile))
#read (MyFile,MyX, MyZ, MyY)
#declare MyArray[MyX][MyZ]=MyY;
#end

#declare i=0;
#declare j=0;

#while(i<LastX)

#while(j<LastZ)
box{0,<-1,MyArray[i][j],-1> translate <-i,0,-j> pigment{green 1}  
finish{ambient 0.5}}
#declare j=j+1;
#end
#declare i=i+1;
#declare j=0;
#end

//end code

I'm not sure why you appear to have a negative X & Z compared to the data  
but this should match your image.

Use whichever you want, switch the MyX, MyY, MyZ variables to suit.

--
Phil Cook

-- 
All thoughts and comments are my own unless otherwise stated and I am  
happy to be proven wrong.

Post a reply to this message

Wasn't it F?bio Dias who wrote:
>Hi!
>I am trying to use povray to generate a 3d surface from a big matrix of real
>numbers, which are the output of my program. I read a lot of things about
>povray, the documentation, etc, but i really don't know how i can do it.
>Everthing i need is a light_source, a camera and this surface. Nothing more.
>Somebody may help me to make a simple .pov file, which my program will
>generate, only changing the parameters?
>(ps: if i did any mistake in my english, i'm sorry in advance!)

I don't think that there's anything like that which POV supports
directly. One thing you could do is to generate an image where the
brightness of the points corresponds to the heights, then use that image
as a Height_Field.

I did it by using a perl script to read your data file and write out an
image in PPM format. The little-known PPM format is useful for such
tasks because the data is represented by ascii strings rather than
binary values.

A PPM file looks a bit like this

P3
240 240
255
1 1 1 3 3 3 0 0 0 0 0 0 0 0 0 0 0 0 3 3 3 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 20 20 20 0 0 0 0 0 0 0 0
0 0 0 0 20 20 20 1 1 1 1 1 1 5 5 5 5 5 5 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 3 3 3 0 0 0 0 0 0 1 1 1 3 3 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3
3 3 0 0 0 0 0 0 0 0 0 0 0 0 3 3 3 0 0 0 0 0 0 0 0 0 0 0 0 3 3 3 3 3 3 0
0 0 0 0 0 3 3 3 3 3 3 0 0 0 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5
5 5 5 5 5 5 5 5 3 3 3 3 3 3 0 0 0 3 ...

The first line is "P3"

The second line is the numbers of pixels in the X and Y directions. Set
it to the dimensions of your matrix.

The third line is the number of shades per colour. Leave this as 255.

The remainder of the file is a sequence of R G B values. Use your data
to generate these entries. I suggest setting the three RGB values all
equal to the "height" value from your matrix. E.g.

Your data       PPM entry

  0 0 1         1 1 1
  0 1 3         3 3 3
  0 2 0         0 0 0
  0 3 0         0 0 0
  0 4 0         0 0 0
  0 5 0         0 0 0
  0 6 3         3 3 3
  0 7 1         1 1 1
  ...           ...

Then, in POV you can do something like

height_field {ppm "superficie.ppm"
  pigment {rgb <0,0.5,0>}
  translate <-0.5,0,-0.5>
  scale 2
}


-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

"Phil Cook" <phi### [at] nospamdeckingdealscouk> wrote in message
news:opr93snpswefp2ch@news.povray.org...

:snip:

>
> Uses boxes rather than points and might be slow with a *lot* of data (this
> took 26 sec on my computer, 76800 objects) but I hope it helps.
>
> --
> Phil Cook
>
> -- 
> All thoughts and comments are my own unless otherwise stated and I am
> happy to be proven wrong.


couldn't you use a bicubic_patch object, assuming each line in the data file
is a point in 3d space?

Post a reply to this message

Mike Williams nous apporta ses lumieres ainsi en ce 24/06/2004 03:20... :

>
>A PPM file looks a bit like this
>
>P3
>240 240
>255
>1 1 1 3 3 3 0 0 0 0 0 0 0 0 0 0 0 0 3 3 3 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0
>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 20 20 20 0 0 0 0 0 0 0 0
>0 0 0 0 20 20 20 1 1 1 1 1 1 5 5 5 5 5 5 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0
>0 0 3 3 3 0 0 0 0 0 0 1 1 1 3 3 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3
>3 3 0 0 0 0 0 0 0 0 0 0 0 0 3 3 3 0 0 0 0 0 0 0 0 0 0 0 0 3 3 3 3 3 3 0
>0 0 0 0 0 3 3 3 3 3 3 0 0 0 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5
>5 5 5 5 5 5 5 5 3 3 3 3 3 3 0 0 0 3 ...
>
>The first line is "P3"
>  
>
Looking at this, I think that you could generate that PPM file directly, 
as you said that you can adjust the format/syntax as needed.
When reading RGB values for a hight_field, POV Ray use the red and green 
chanels to determine a 16 bits value for the hight of each elements. Low 
values under 256 use only the red, values greater than 255 start using 
the green chanel, the blue chanel is ignored. Unscaled hight_field are 
1*1*1 arbitrary unit and must be scaled to the size you want.

Alain

Post a reply to this message

And lo on Thu, 24 Jun 2004 14:32:50 -0400, Ross <rli### [at] everestkcnet>  
did spake, saying:

> "Phil Cook" <phi### [at] nospamdeckingdealscouk> wrote in message
> news:opr93snpswefp2ch@news.povray.org...
>
> :snip:
>
>>
>> Uses boxes rather than points and might be slow with a *lot* of data  
>> (this
>> took 26 sec on my computer, 76800 objects) but I hope it helps.
>>
>> --
>> Phil Cook
>>
>> --
>> All thoughts and comments are my own unless otherwise stated and I am
>> happy to be proven wrong.
>
>
> couldn't you use a bicubic_patch object, assuming each line in the data  
> file
> is a point in 3d space?

I wasn't keen on the fact that the control-point doesn't necessarily  
represent the actual point co-ords and that as a bicubic patch it only  
allows 16 vector points which means dividing the data file into 4x4 'sets'  
<0,0,Y>,<4,0,Y> to <4,0,Y,>, <4,4,Y> etc. and then recreating the patch  
with the correct data 'set' each time. Of course you have to assume the  
data is divisible by 16 or pad it. I must admit with the code here I  
assumed it was square, but that's easily changed.

It seemed to fiddly to do with a bicubic patch, though of course if you  
care to try I'd be interested in seeing your code :)

--
Phil Cook

-- 
All thoughts and comments are my own unless otherwise stated and I am  
happy to be proven wrong.

Post a reply to this message

In article <opr93snpswefp2ch@news.povray.org>,
 "Phil Cook" <phi### [at] nospamdeckingdealscouk> wrote:

> Uses boxes rather than points and might be slow with a *lot* of data (this  
> took 26 sec on my computer, 76800 objects) but I hope it helps.

It would be far faster, more space efficient, and probably better 
looking to use a mesh instead.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <$O7jtAAKDo2AFws$@econym.demon.co.uk>,
 Mike Williams <nos### [at] econymdemoncouk> wrote:

> I did it by using a perl script to read your data file and write out an
> image in PPM format. The little-known PPM format is useful for such
> tasks because the data is represented by ascii strings rather than
> binary values.

The PGM variant would be more useful for this purpose. Just use P2 
instead of P3, and include each value only once. However, I don't know 
if POV will read this...I think it should, it's not exactly a difficult 
format.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

"Phil Cook" <phi### [at] nospamdeckingdealscouk> wrote in message
news:opr95d41q8efp2ch@news.povray.org...
> And lo on Thu, 24 Jun 2004 14:32:50 -0400, Ross <rli### [at] everestkcnet>
> did spake, saying:
>
> > "Phil Cook" <phi### [at] nospamdeckingdealscouk> wrote in message
> > news:opr93snpswefp2ch@news.povray.org...
> >
> > :snip:
> >
> >>
> >> Uses boxes rather than points and might be slow with a *lot* of data
> >> (this
> >> took 26 sec on my computer, 76800 objects) but I hope it helps.
> >>
> >> --
> >> Phil Cook
> >>
> >> --
> >> All thoughts and comments are my own unless otherwise stated and I am
> >> happy to be proven wrong.
> >
> >
> > couldn't you use a bicubic_patch object, assuming each line in the data
> > file
> > is a point in 3d space?
>
> I wasn't keen on the fact that the control-point doesn't necessarily
> represent the actual point co-ords and that as a bicubic patch it only
> allows 16 vector points which means dividing the data file into 4x4 'sets'
> <0,0,Y>,<4,0,Y> to <4,0,Y,>, <4,4,Y> etc. and then recreating the patch
> with the correct data 'set' each time. Of course you have to assume the
> data is divisible by 16 or pad it. I must admit with the code here I
> assumed it was square, but that's easily changed.
>
> It seemed to fiddly to do with a bicubic patch, though of course if you
> care to try I'd be interested in seeing your code :)
>
> --
> Phil Cook
>

i was mostly just curious, as i tend to not use bicubic patches. Ah well.

Post a reply to this message