Hi

i have an object which i don't know the dimensions (created by an external
script) Now i want to show this object as full image (to fill most of the
image but nothing of the object should be hidden) and so I have to
automaticly calculate the position of the camera. How can i do this? I think
i can do this using max_extend and min_extend. But how without a lot of
calculations? Is there an easy way?

Setting the camera manually is not an option. I have about 500 of this
objects and they are all different.
It is for my converter from Eagle (a PCB layout programm) to POVRay.


--

mat### [at] matweide
http://www.matwei.de

Post a reply to this message

Using the max/min_extend functions seems to be the correct way to do it, 
I would then center it, and compute the camera position according to the 
size of the object, but I don't expect a lot of calculations for that. 
You should be able to set a correct position with a few test and tries.
You can also have a fixed camera and scale your objects to fit in a 
given box, for example box { -1, 1 }, you would have to find their 
biggest dimension and then scale that dimension to the box.

I hope that helps,

JC (Exether)


> Hi
> 
> i have an object which i don't know the dimensions (created by an external
> script) Now i want to show this object as full image (to fill most of the
> image but nothing of the object should be hidden) and so I have to
> automaticly calculate the position of the camera. How can i do this? I think
> i can do this using max_extend and min_extend. But how without a lot of
> calculations? Is there an easy way?
> 
> Setting the camera manually is not an option. I have about 500 of this
> objects and they are all different.
> It is for my converter from Eagle (a PCB layout programm) to POVRay.
> 
> 
> --

> mat### [at] matweide
> http://www.matwei.de
> 
> 
> 
>

Post a reply to this message

Hi guys!

> You can also have a fixed camera and scale your objects to fit in a 
> given box, for example box { -1, 1 }, you would have to find their 
> biggest dimension and then scale that dimension to the box.
I think that's the better one of the two possibilites. This way he can 
use different camera-types (orthographic etc.) and parametres (like 
angle...). Position the camera should be no problem using Trial&Error 
(TM), but calculating it?

So better go and fit your target in the box :)

HTH,
Florian
-- 
//=================[web: http://www.torfbold.com]==================\\
#local a=-5;#while(a<5)sphere{<sin(a*pi)*5a*10pow(a,5)*.01>sin(a*a*a*
.1)+1pigment{rgb 9*z}}#local a=a+.01;#end camera{look_at-y*10location
<8,-3,-8>*10}// [www.povray.org]     [www.imp.org]     [www.irtc.org]

Post a reply to this message

On Mon, 08 Sep 2003 16:24:43 +0200, Florian Brucker <tor### [at] torfboldcom> 
wrote:

> Hi guys!
>
>> You can also have a fixed camera and scale your objects to fit in a 
>> given box, for example box { -1, 1 }, you would have to find their 
>> biggest dimension and then scale that dimension to the box.
> I think that's the better one of the two possibilites. This way he can 
> use different camera-types (orthographic etc.) and parametres (like 
> angle...). Position the camera should be no problem using Trial&Error 
> (TM), but calculating it?
>
> So better go and fit your target in the box :)
>
> HTH,
> Florian

Just out of curiosity, as a newbie would this work?
--
Phil

//POV file starts here
camera{
location <0.5,3,-3>
look_at <0.5,0.5,0.5>
}
//just for this exercise create an object
#declare Object = box{<-5,-10,-3>,<3,7,5> pigment {rgb <1,0,0>} 
finish{ambient 0.6 diffuse 0.4}}

#declare Minimum = min_extent(Object);
#declare Maximum = max_extent(Object);

#declare TotalX = abs(Minimum.x)+ abs(Maximum.x);
#declare TotalY = abs(Minimum.y)+ abs(Maximum.y);
#declare TotalZ = abs(Minimum.z)+ abs(Maximum.z);

#declare FirstTest = (TotalX>TotalY ? TotalX:TotalY);
#declare MaxLength = (TotalZ>FirstTest ? TotalZ:FirstTest);

//for bounding box of 1 unit

object{Object  translate <-Minimum.x,-Minimum.y,-Minimum.z> scale 
(1/MaxLength)}

//show bounds
sphere{<0,0,0>,0.1  pigment {rgbt <0,1,0,0.5>} finish{ambient 0.4 diffuse 
0.6}}
sphere{<1,0,0>,0.1  pigment {rgbt <0,1,0,0.5>} finish{ambient 0.4 diffuse 
0.6}}
sphere{<0,1,0>,0.1  pigment {rgbt <0,1,0,0.5>} finish{ambient 0.4 diffuse 
0.6}}
sphere{<0,0,1>,0.1  pigment {rgbt <0,1,0,0.5>} finish{ambient 0.4 diffuse 
0.6}}
sphere{<1,1,0>,0.1  pigment {rgbt <0,1,0,0.5>} finish{ambient 0.4 diffuse 
0.6}}
sphere{<1,0,1>,0.1  pigment {rgbt <0,1,0,0.5>} finish{ambient 0.4 diffuse 
0.6}}
sphere{<0,1,1>,0.1  pigment {rgbt <0,1,0,0.5>} finish{ambient 0.4 diffuse 
0.6}}
sphere{<1,1,1>,0.1  pigment {rgbt <0,1,0,0.5>} finish{ambient 0.4 diffuse 
0.6}}
//POV file end here
-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Post a reply to this message

Hi all!

> object{Object  translate <-Minimum.x,-Minimum.y,-Minimum.z> scale 
> (1/MaxLength)}

imagine a box:

	box { <1,1,1>,<2,2,2> }

Minimum would be <1,1,1>, Maximum <2,2,2>. translating it by:

	translate <-Minimum.x,-Minimum.y,-Minimum.z>

(which is btw the same as "translate -Minimum") would result in the 
following box:

	box { <0,0,0>,<1,1,1> }

this box is not centered at the origin.
This one is better:

	translate -(Minimum+Maximum)/2

(Minimum+Maximum)/2 is the center of the bounding box.

Rest looks fine (didn't test it though)

HTH,
Florian
-- 
//=================[web: http://www.torfbold.com]==================\\
#local a=-5;#while(a<5)sphere{<sin(a*pi)*5a*10pow(a,5)*.01>sin(a*a*a*
.1)+1pigment{rgb 9*z}}#local a=a+.01;#end camera{look_at-y*10location
<8,-3,-8>*10}// [www.povray.org]     [www.imp.org]     [www.irtc.org]

Post a reply to this message

Florian Brucker wrote:
> Hi guys!
>
>> You can also have a fixed camera and scale your objects to fit in a
>> given box, for example box { -1, 1 }, you would have to find their
>> biggest dimension and then scale that dimension to the box.
> I think that's the better one of the two possibilites. This way he can

I did it that way (resize/translate my objects in a box { -1, 1 })
Works very well. A lot better than trying out 600 camarea positions. Thanks
a lot.



--

mat### [at] matweide
http://www.matwei.de

Post a reply to this message

Hi Phil and Florian!

Because the camera's look-at is <.5,.5,.5>, a box{0,1} is exactly what
is needed, but unfortunately Phil's calculations are a bit wrong: they
only work if Minimum.x and Maximum.x have different sign or one of them
is zero. (Similar for .y, .z.) The correct formulas are

  #declare TotalX = Maximum.x-Minimum.x;
  #declare TotalY = Maximum.y-Minimum.y;
  #declare TotalZ = Maximum.z-Minimum.z;

abs is not required.
The calculation of MaxLength can be simplified to

  #declare MaxLength = max(TotalX,TotalY,TotalZ);

or, compressing all this into one statement:

  #declare MaxLength = max(
    Maximum.x-Minimum.x,
    Maximum.y-Minimum.y,
    Maximum.z-Minimum.z );


The vector <-Minimum.x,-Minimum.y,-Minimum.z> is the same as -Minimum,
so positioning of the Object is done by

  object { Object translate -Minimum scale 1/MaxLength }


The spheres for indication of the bounds are more easily readable as

union {
  sphere{<0,0,0>,0.1}
  sphere{<1,0,0>,0.1}
  sphere{<0,1,0>,0.1}
  sphere{<0,0,1>,0.1}
  sphere{<1,1,0>,0.1}
  sphere{<1,0,1>,0.1}
  sphere{<0,1,1>,0.1}
  sphere{<1,1,1>,0.1}
  pigment {rgbt <0,1,0,0.5>} finish{ambient 0.4 diffuse 0.6}
  }


So, aside from the errors with TotalX/Y/Z, Phil's code is correct.
But I agree with Florian that a box{-0.5,0.5} might be better because
the look_at would be 0 in this case which makes the placement of the
camera a bit easier: I prefer to define the position of the camera by
rotation (instead of absolute coordinates), which is easier with a
look_at of 0. For example:

  camera { location -Distance*z look_at 0 rotate <Elevation,Rotation,0> }

Distance should be chosen in such a way that all points of the Object are
visible for arbitrary values of Elevation and Rotation. The maximum
distance from the origin of a point in a box{-0.5,0.5} is sqrt(3*0.5^2)
=sqrt(0.75). All the points with this distance from the origin lie on a
sphere{0,sqrt(0.75)}. If this sphere is completely visible, then the
Object also is completely visible regardless of rotations of the camera.
A bit of calculation reveals a neccessary Distance of sqrt(3.75)=1.9365
(or more, for example 2) for a standard camera.

   Sputnik

Post a reply to this message

<fr### [at] computermuseumfh-kielde> wrote:

> Hi Phil and Florian!
>
> Because the camera's look-at is <.5,.5,.5>, a box{0,1} is exactly what
> is needed, but unfortunately Phil's calculations are a bit wrong: they
> only work if Minimum.x and Maximum.x have different sign or one of them
> is zero. (Similar for .y, .z.) The correct formulas are
>
> #declare TotalX = Maximum.x-Minimum.x;
> #declare TotalY = Maximum.y-Minimum.y;
> #declare TotalZ = Maximum.z-Minimum.z;
>
> abs is not required.
> The calculation of MaxLength can be simplified to
>
> #declare MaxLength = max(TotalX,TotalY,TotalZ);
>
> or, compressing all this into one statement:
>
> #declare MaxLength = max(
> Maximum.x-Minimum.x,
> Maximum.y-Minimum.y,
> Maximum.z-Minimum.z );
>
>
> The vector <-Minimum.x,-Minimum.y,-Minimum.z> is the same as -Minimum,
> so positioning of the Object is done by
>
> object { Object translate -Minimum scale 1/MaxLength }
>
>
> The spheres for indication of the bounds are more easily readable as
>
> union {
> sphere{<0,0,0>,0.1}
> sphere{<1,0,0>,0.1}
> sphere{<0,1,0>,0.1}
> sphere{<0,0,1>,0.1}
> sphere{<1,1,0>,0.1}
> sphere{<1,0,1>,0.1}
> sphere{<0,1,1>,0.1}
> sphere{<1,1,1>,0.1}
> pigment {rgbt <0,1,0,0.5>} finish{ambient 0.4 diffuse 0.6}
> }
>
>
> So, aside from the errors with TotalX/Y/Z, Phil's code is correct.
> But I agree with Florian that a box{-0.5,0.5} might be better because
> the look_at would be 0 in this case which makes the placement of the
> camera a bit easier: I prefer to define the position of the camera by
> rotation (instead of absolute coordinates), which is easier with a
> look_at of 0. For example:
>
> camera { location -Distance*z look_at 0 rotate <Elevation,Rotation,0> }
>
> Distance should be chosen in such a way that all points of the Object are
> visible for arbitrary values of Elevation and Rotation. The maximum
> distance from the origin of a point in a box{-0.5,0.5} is sqrt(3*0.5^2)
> =sqrt(0.75). All the points with this distance from the origin lie on a
> sphere{0,sqrt(0.75)}. If this sphere is completely visible, then the
> Object also is completely visible regardless of rotations of the camera.
> A bit of calculation reveals a neccessary Distance of sqrt(3.75)=1.9365
> (or more, for example 2) for a standard camera.
>
> Sputnik
>
>
>

Thanks Florian and Sputnik for the pointers, I slapped myself on the head 
when I looked at the the #declare for TotalX etc., I actually looked up max 
but saw it was for floats and I was thinking in vectors at the time duh!
I actually placed the min_extent at the origin as I have had some strange 
results in scaling objects away from it, as follows:

//POVWin 3.5 file starts here
camera{
location <17,50,-100>
look_at <17,25,0>
}

#declare unitdivider = union{
box{0,<35,52-6,-2.3>}
cylinder{<0,0,0>,<0,0,-2.3>, 6 scale <35/12,1,1> translate <35/2,52-6,0>}
//cylinder{<0,0,0>,<0,0,-2.3>, 6 translate <35/2,52-6,0> scale <35/12,1,1>}
pigment{rgb <1,0,0>} finish{ambient 0.6 diffuse 0.4}
}

object{unitdivider}
//POV file ends here

If I translate then scale as per commented out line, the cylinder floats to 
+x of the box. Shifting the 35/12 to y and z produces the same results in 
the obvious directions.

I've just tried the combined code from you and Florian, and that works fine 
though, of course:).

Am I doing something fundamentally stupid?

--
Phil


-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Post a reply to this message

On Tue, 09 Sep 2003 12:45:31 +0100, Phil Cook <phi### [at] deckingdealscouk> 
wrote:


> <fr### [at] computermuseumfh-kielde> wrote:
>
>> Hi Phil and Florian!
>>
>> Because the camera's look-at is <.5,.5,.5>, a box{0,1} is exactly what
>> is needed, but unfortunately Phil's calculations are a bit wrong: they
>> only work if Minimum.x and Maximum.x have different sign or one of them
>> is zero. (Similar for .y, .z.) The correct formulas are
>>
>> #declare TotalX = Maximum.x-Minimum.x;
>> #declare TotalY = Maximum.y-Minimum.y;
>> #declare TotalZ = Maximum.z-Minimum.z;
>>
>> abs is not required.
>> The calculation of MaxLength can be simplified to
>>
>> #declare MaxLength = max(TotalX,TotalY,TotalZ);
>>
>> or, compressing all this into one statement:
>>
>> #declare MaxLength = max(
>> Maximum.x-Minimum.x,
>> Maximum.y-Minimum.y,
>> Maximum.z-Minimum.z );
>>
>>
>> The vector <-Minimum.x,-Minimum.y,-Minimum.z> is the same as -Minimum,
>> so positioning of the Object is done by
>>
>> object { Object translate -Minimum scale 1/MaxLength }
>>
>>
>> The spheres for indication of the bounds are more easily readable as
>>
>> union {
>> sphere{<0,0,0>,0.1}
>> sphere{<1,0,0>,0.1}
>> sphere{<0,1,0>,0.1}
>> sphere{<0,0,1>,0.1}
>> sphere{<1,1,0>,0.1}
>> sphere{<1,0,1>,0.1}
>> sphere{<0,1,1>,0.1}
>> sphere{<1,1,1>,0.1}
>> pigment {rgbt <0,1,0,0.5>} finish{ambient 0.4 diffuse 0.6}
>> }
>>
>>
>> So, aside from the errors with TotalX/Y/Z, Phil's code is correct.
>> But I agree with Florian that a box{-0.5,0.5} might be better because
>> the look_at would be 0 in this case which makes the placement of the
>> camera a bit easier: I prefer to define the position of the camera by
>> rotation (instead of absolute coordinates), which is easier with a
>> look_at of 0. For example:
>>
>> camera { location -Distance*z look_at 0 rotate <Elevation,Rotation,0> }
>>
>> Distance should be chosen in such a way that all points of the Object 
>> are
>> visible for arbitrary values of Elevation and Rotation. The maximum
>> distance from the origin of a point in a box{-0.5,0.5} is sqrt(3*0.5^2)
>> =sqrt(0.75). All the points with this distance from the origin lie on a
>> sphere{0,sqrt(0.75)}. If this sphere is completely visible, then the
>> Object also is completely visible regardless of rotations of the camera.
>> A bit of calculation reveals a neccessary Distance of sqrt(3.75)=1.9365
>> (or more, for example 2) for a standard camera.
>>
>> Sputnik
>>
>>
>>
>
> Thanks Florian and Sputnik for the pointers, I slapped myself on the head 
> when I looked at the the #declare for TotalX etc., I actually looked up 
> max but saw it was for floats and I was thinking in vectors at the time 
> duh!
> I actually placed the min_extent at the origin as I have had some strange 
> results in scaling objects away from it, as follows:
>
> //POVWin 3.5 file starts here
> camera{
> location <17,50,-100>
> look_at <17,25,0>
> }
>
> #declare unitdivider = union{
> box{0,<35,52-6,-2.3>}
> cylinder{<0,0,0>,<0,0,-2.3>, 6 scale <35/12,1,1> translate <35/2,52-6,0>}
> //cylinder{<0,0,0>,<0,0,-2.3>, 6 translate <35/2,52-6,0> scale 
> <35/12,1,1>}
> pigment{rgb <1,0,0>} finish{ambient 0.6 diffuse 0.4}
> }
>
> object{unitdivider}
> //POV file ends here
>
> If I translate then scale as per commented out line, the cylinder floats 
> to +x of the box. Shifting the 35/12 to y and z produces the same results 
> in the obvious directions.
>
> I've just tried the combined code from you and Florian, and that works 
> fine though, of course:).
>
> Am I doing something fundamentally stupid?
>
> --
> Phil
>
>

Well looks like I can answer my own question, after a bit of 
experimentation I think the following explains the scaling situation,

//original sphere
sphere{<1,1,1>, 1  pigment{rgbt <1,0,0,0.6>} finish{ambient 0.6 diffuse 
0.4}}
//centre of original sphere
sphere{<1,1,1>, 0.5  pigment{rgb <0,1,0>} finish{ambient 0.6 diffuse 0.4}}
//same sphere scaled
sphere{<1,1,1>, 1  pigment{rgbt <1,0,0,0.6>} finish{ambient 0.6 diffuse 
0.4} scale 2}
//center of new sphere
sphere{<2,2,2>, 0.5  pigment{rgb <0,0,1>} finish{ambient 0.6 diffuse 0.4}}

So
sphere{<1,1,1>,1 scale 2} is equivalent to a sphere{<2,2,2>,2}

cylinder{<1,1,1>,<1,3,1>, 1 scale 2} is a cylinder{<2,2,2>, <2,6,2>,2}
and
box{<1,1,1>,<3,3,3> scale 2} is a box{<2,2,2>,<6,6,6>}

which makes sense just multiple the vectors by the scale, it's a shame that 
the help file uses a 0 sphere as it's example, as this won't show any 
translation (0*any number =0).

This is probably well known and understood by POV-Ray writers more 
competent than myself, but it confused the heck out of me at first.

--
Phil

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Post a reply to this message

"Phil Cook" <phi### [at] deckingdealscouk> wrote in message
news:opru931zpaeybzwd@news.povray.org...
>
> Well looks like I can answer my own question, after a bit of
> experimentation I think the following explains the scaling situation,

<snip>

> which makes sense just multiple the vectors by the scale, it's a shame that
> the help file uses a 0 sphere as it's example, as this won't show any
> translation (0*any number =0).
>
> This is probably well known and understood by POV-Ray writers more
> competent than myself, but it confused the heck out of me at first.
>

I think everyone runs into this one at some moment - it's very tied in to the
(wrong) assumption that every pov-primitive has a defined center (which could
therefore stay in one place even when the object is scaled).

Without a defined center, how could any object stay in one place when you
changed its size?

The bottom line is that it's a good idea to locate a known point of your object
at <0,0,0> prior to scaling.

Extending this to all the transforms, except in special cases*, I tend to follow
what I call the 'open the door' rule - grasp the handle (scale), turn (rotate),
open (translate).

* for example, for the markers on a clock-face, I would tend to translate first,
then rotate.

Post a reply to this message