![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
And lo on Thu, 24 Jun 2004 14:32:50 -0400, Ross <rli### [at] everestkc net>
did spake, saying:
> "Phil Cook" <phi### [at] nospamdeckingdeals co uk> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <opr93snpswefp2ch@news.povray.org>,
"Phil Cook" <phi### [at] nospamdeckingdeals co uk> 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] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tag povray org>
http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <$O7jtAAKDo2AFws$@econym.demon.co.uk>,
Mike Williams <nos### [at] econym demon co uk> 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] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tag povray org>
http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Phil Cook" <phi### [at] nospamdeckingdeals co uk> wrote in message
news:opr95d41q8efp2ch@news.povray.org...
> And lo on Thu, 24 Jun 2004 14:32:50 -0400, Ross <rli### [at] everestkc net>
> did spake, saying:
>
> > "Phil Cook" <phi### [at] nospamdeckingdeals co uk> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
And lo on Fri, 25 Jun 2004 12:28:03 +0100, Phil Cook
<phi### [at] nospamdeckingdeals co uk> did spake, saying:
> And lo on Thu, 24 Jun 2004 14:32:50 -0400, Ross
> <rli### [at] everestkc net> did spake, saying:
>
>> "Phil Cook" <phi### [at] nospamdeckingdeals co uk> 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 :)
Just to prove it can be done though crudely and with no error-checking
//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]=<MyX,MyY,MyZ>;
#end
#macro PatchDraw()
bicubic_patch{
type 0
flatness 0.01
u_steps 4
v_steps 4
MyArray[i][j],MyArray[i][j+1],MyArray[i][j+2],MyArray[i][j+3],
MyArray[i+1][j],MyArray[i+1][j+1],MyArray[i+1][j+2],MyArray[i+1][j+3],
MyArray[i+2][j],MyArray[i+2][j+1],MyArray[i+2][j+2],MyArray[i+2][j+3],
MyArray[i+3][j],MyArray[i+3][j+1],MyArray[i+3][j+2],MyArray[i+3][j+3]
pigment{green 1}
finish{ambient 0.3}
}
#end
#declare i=0;
#declare j=0;
#while(i<LastX)
#while(j<LastZ)
PatchDraw()
#declare j=j+4;
#end
#declare i=i+4;
#declare j=0;
#end
//end code
Though this takes about 50 odd seconds compared to 20 odd for the boxes.
To join them up change the last part to:
#while(i<LastX-3)
#while(j<LastZ-3)
PatchDraw()
#declare j=j+3;
#end
#declare i=i+3;
#declare j=0;
#end
Hmm this ran at 44sec
To use all the data then both X-3 and Z-3 need to be divisible by 4; with
this data that means 0,0,Y to 322,242,Y
Certainly looks smoother :)
--
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
And lo on Fri, 25 Jun 2004 08:52:12 -0500, Christopher James Huff
<cja### [at] earthlink net> did spake, saying:
> In article <opr93snpswefp2ch@news.povray.org>,
> "Phil Cook" <phi### [at] nospamdeckingdeals co uk> 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.
I'm not sure how you would do that if you tried to join them in a row you
could end up with a triangle{<0,0,4>,<0,0,5>,<0,3,6>} even if you use each
point separately and created two flat points each side as
triangle{<-0.5,0,0>,<0,1,0>[data],<0.5,0,0>} you would still end up with
distinct rows unless you create additional triangles to bridge the rows
and I still think it would look a bit granular.
I've probably missed something so I would be curious as to how you would
do it?
Okay saying that here's how I would do it:
//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,100,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]=<MyX,MyY,MyZ>;
#end
#declare i=0;
#declare j=0;
mesh{
#while(j<LastZ)
#while(i<LastX)
triangle{
<MyArray[i][j].x-0.5,0,MyArray[i][j].z>,MyArray[i][j],<MyArray[i][j].x+0.5,0,MyArray[i][j].z>
}
#declare i=i+1;
#end
#declare j=j+1;
#declare i=0;
#end
pigment{green 1}
}
plane{y,0 pigment{rgb 1}}
//end code
runs in 18 sec on mine, but I don't think it looks as good as the box or
patch version.
--
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Thanks for everbody!
i have some things to say:
The first solution works very fine, but it generates a "punched" surface
(not so continuos). And, if possible, i wanna know why, and how to fix it.
Let me explain a bit more about my project...
This surface will be used for presentations, and (if I make my program and
pov talk) for user interface. It is a 3d representation of a fuzzy
probabilistical distribution, for color based object seaching, a piece of
my undergraduate reseach. I have used 3dmax, but i cannot use it anymore
for legal questions( :-[ ). So I am trying to integrate pov with my
program...
I am using the Open Computer Vision library to access the videos and images,
and I'll test the height_field solution right now, checking the ppm file
saved by opencv...
I'm really impressed with everbody here, it a little dificult to find a
community which helps troubled people (me!).
Again, if I made any mistake with my english, i am sorry.
Thanks
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
<fab### [at] ic unicamp br> did spake, saying:
> Thanks for everbody!
> i have some things to say:
> The first solution works very fine, but it generates a "punched" surface
> (not so continuos). And, if possible, i wanna know why, and how to fix
> it.
>
> Let me explain a bit more about my project...
>
> This surface will be used for presentations, and (if I make my program
> and
> pov talk) for user interface. It is a 3d representation of a fuzzy
> probabilistical distribution, for color based object seaching, a piece of
> my undergraduate reseach. I have used 3dmax, but i cannot use it anymore
> for legal questions( :-[ ). So I am trying to integrate pov with my
> program...
>
> I am using the Open Computer Vision library to access the videos and
> images,
> and I'll test the height_field solution right now, checking the ppm file
> saved by opencv...
I'm not sure what you mean by a 'punched' surface. The only thing I can
think of is with my first coding which used boxes if you had three boxes
height 0,3 and 0 it would be like standing next to a skyscraper. The
second code using the bicubic patch should solve that by smoothing the
points together, did you try that one though you have to watch it uses all
the data.
For proper smoothness the height_field solution from Mike is probably
going to be the best option for you.
> I'm really impressed with everbody here, it a little dificult to find a
> community which helps troubled people (me!).
I've been constantly impressed by everyone here ever since I started using
povray.
> Again, if I made any mistake with my english, i am sorry.
I wouldn't really have noticed if you hadn't mentioned it, you write and
construct better English than some native speakers.
--
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
And lo on Fri, 25 Jun 2004 09:00:54 -0500, Christopher James Huff
<cja### [at] earthlink net> did spake, saying:
> In article <$O7jtAAKDo2AFws$@econym.demon.co.uk>,
> Mike Williams <nos### [at] econym demon co uk> 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.
>
Using a comma seperated dat file:
//start code
#fopen MyFile "superficie.dat" read
#while (defined(MyFile))
#read (MyFile,LastX, LastZ, DitchY)
#end
#declare LastX=LastX+1;
#declare LastZ=LastZ+1;
/*
This is to write put the pgm file
from the comma seperated dat file
and can be commented out once generated
*/
#declare MyArray= array[LastX][LastZ];
#fopen MyFile "superficie.dat" read
#while (defined(MyFile))
#read (MyFile,MyX, MyZ, MyY)
#declare MyArray[MyX][MyZ]=MyY;
#end
#fclose MyFile
#declare i=0;
#declare j=0;
#fopen MyFile "super.pgm" write
#write(MyFile
"P2", "\n",
LastX," ", LastZ, "\n",
"255", "\n")
#while(j<LastZ)
#while(i<LastX)
#if (i=(LastX-1))
#write (MyFile, MyArray[i][j],"\n")
#else
#write (MyFile, MyArray[i][j]," ")
#end
#declare i=i+1;
#end
#declare j=j+1;
#declare i=0;
#end
#fclose MyFile
/*
Put the closing pgm comment here to stop generating the file
*/
camera{
location <-LastX/200,2.0,-1.5>
look_at <-LastX/200,0,LastZ/200>
}
light_source{<-LastX/200,5,LastZ/200> rgb 1 shadowless}
height_field {pgm "super.pgm"
pigment {green 0.5} finish{ambient 0.3}
scale <-LastX/100, 2, LastZ/100>
}
//end code
Seems quicker
--
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Problem solved!!
Thanks a lot, Phil, Mike, and everbody else.
Next friday i'll put a powerpoint slideshow, using Phil's solution, in
www.ic.unicamp.br/~ra015988/lis/artigos/novo/
Everbody is invited to see it.
Thanks a lot, and if anyone have C ou C++ problems, just mail me. :-)
"Phil Cook" <phi### [at] nospamdeckingdeals co uk> wrote:
> And lo on Fri, 25 Jun 2004 09:00:54 -0500, Christopher James Huff
> <cja### [at] earthlink net> did spake, saying:
>
> > In article <$O7jtAAKDo2AFws$@econym.demon.co.uk>,
> > Mike Williams <nos### [at] econym demon co uk> 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.
> >
>
> Using a comma seperated dat file:
>
> //start code
> #fopen MyFile "superficie.dat" read
> #while (defined(MyFile))
> #read (MyFile,LastX, LastZ, DitchY)
> #end
>
> #declare LastX=LastX+1;
> #declare LastZ=LastZ+1;
>
> /*
> This is to write put the pgm file
> from the comma seperated dat file
> and can be commented out once generated
> */
> #declare MyArray= array[LastX][LastZ];
>
> #fopen MyFile "superficie.dat" read
> #while (defined(MyFile))
> #read (MyFile,MyX, MyZ, MyY)
> #declare MyArray[MyX][MyZ]=MyY;
> #end
> #fclose MyFile
> #declare i=0;
> #declare j=0;
>
> #fopen MyFile "super.pgm" write
> #write(MyFile
> "P2", "n",
> LastX," ", LastZ, "n",
> "255", "n")
>
> #while(j<LastZ)
>
> #while(i<LastX)
> #if (i=(LastX-1))
> #write (MyFile, MyArray[i][j],"n")
> #else
> #write (MyFile, MyArray[i][j]," ")
> #end
> #declare i=i+1;
> #end
> #declare j=j+1;
> #declare i=0;
> #end
> #fclose MyFile
> /*
> Put the closing pgm comment here to stop generating the file
> */
>
> camera{
> location <-LastX/200,2.0,-1.5>
> look_at <-LastX/200,0,LastZ/200>
> }
>
> light_source{<-LastX/200,5,LastZ/200> rgb 1 shadowless}
>
>
> height_field {pgm "super.pgm"
> pigment {green 0.5} finish{ambient 0.3}
> scale <-LastX/100, 2, LastZ/100>
>
> }
> //end code
>
> Seems quicker
>
> --
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |