Alain <ele### [at] netscapenet> wrote:
> >
> For a "default" camera where the right vector have been changed, the
> horizontal field of view don't change with the right vector. The
> direction vector can be used to change the angle of the field of view.
> In early versions, before the angle keyword was introduced, it was
> the only way to change the field of view.
>
> The up and right vectors determine the aspect ratio. They work by changing the
> vertical field of view.


Okay, yes, they change the aspect ratio, and they can mess it up by giving you a
scenario where circles are not circular if you're not using 4x3 pixel ratio.

So, I'm doing:

 right x*1.33
 up image_height/image_width*y*1.33

Now, regardless of what I do with the +H and +W switches, circles will be
circular.   The problem is I may want to change the angle at some time. With
the above code, I *can* change the horizontal field of view with:


 right x*the_right
 up image_height/image_width*y*the_right

where I plug in a number for "the_right".   I guess I'm looking for a good
camera definition, a graphical image of what all the vectors mean in the
default camera.  The one at

http://www.povray.org/documentation/view/3.6.1/246/

is completely lacking for the definition of a default camera.  Is 1.33 the x
distance seen at the plane <0,0,1>???

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

gregjohn wrote:
> Alain <ele### [at] netscapenet> wrote:
>> For a "default" camera where the right vector have been changed, the
>> horizontal field of view don't change with the right vector. The
>> direction vector can be used to change the angle of the field of view.
>> In early versions, before the angle keyword was introduced, it was
>> the only way to change the field of view.
>>
>> The up and right vectors determine the aspect ratio. They work by changing the
>> vertical field of view.
> 
> 
> Okay, yes, they change the aspect ratio, and they can mess it up by giving you a
> scenario where circles are not circular if you're not using 4x3 pixel ratio.
> 
> So, I'm doing:
> 
>  right x*1.33
>  up image_height/image_width*y*1.33
> 
> Now, regardless of what I do with the +H and +W switches, circles will be
> circular.   The problem is I may want to change the angle at some time. With
> the above code, I *can* change the horizontal field of view with:
> 
> 
>  right x*the_right
>  up image_height/image_width*y*the_right
> 
> where I plug in a number for "the_right".   I guess I'm looking for a good
> camera definition, a graphical image of what all the vectors mean in the
> default camera.  The one at
> 
> http://www.povray.org/documentation/view/3.6.1/246/
> 
> is completely lacking for the definition of a default camera.  Is 1.33 the x
> distance seen at the plane <0,0,1>???
> 
	The relation between angle and right is:
tan (angle/2) = ||right|| / (2 * ||direction||)

	(note that it is given in the page you pointed to).

	Moreover, direction is ||look_at - location|| / 2

		Jerome
- --
mailto:jeb### [at] freefr
http://jeberger.free.fr
Jabber: jeb### [at] jabberfr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkmo4eYACgkQd0kWM4JG3k/znQCeP1wlXDy7Ighn0SC3rsb8Cu9n
NcsAnRnOB2ORrp2LvoWPtYvJAb513Eha
=ehVc
-----END PGP SIGNATURE-----

Post a reply to this message

"gregjohn" <pte### [at] yahoocom> wrote:
> Now, regardless of what I do with the +H and +W switches, circles will be
> circular.   The problem is I may want to change the angle at some time. With
> the above code, I *can* change the horizontal field of view with:

If all you need to do is set proper values, then why mess with the
right/left/direction if you can have it simple?

    location   MyCameraPos
    direction  z
    up         y
    right      x*image_width/image_height
    look_at    MyWhateverImLookingAt
    angle      MyAngle

There. This will place MyWhateverImLookingAt right at the center of your image,
with any vertical line throuh that point being rendered as a vertical line in
the image, the angle between the center points on the left and right screen
edges being MyAngle, and the aspect ratio set to something proper.

The opening angle of MyAngle will result in objects' apparent size in pixels to
be

    Size*image_width/(Dist*2*tan(MyAngle/2))

where Size and Dist are the object's size and its distance from camera,
respectively.

I have no idea what the effects are of choosing different direction, up and/or
right vectors, but this one works reliably. No need to fuss around with any
friggin' 1.33.

Choose right -x*image_width/image_height if you're not happy with the
co-ordinate system handedness (I guess choosing direction -z would do the same
job but I didn't test).

Note that the order of statements may matter.

Post a reply to this message

I want complete control of the screen. For example, I want to be able to place a
sphere at the corner of the generated image, no matter what the pixel size or
ratio of the image, no matter the angle (however it's defined).

I've got a way to do this using an obtuse use of the right vector.  It works
perfectly for the camera in the default location. If I want to look somewhere
else, I can simply apply a transform to both the camera and the object.  Using
the formula in that is in the docs doesn't work immediately in my code.  I
suspect the docs aren't completely telling us how the camera actually works--
that image sure as heck doesn't.  There are a bunch of parameters that can be
played with, but I don't know how the camera actually WORKS.

Q: Has anyone seen a more descriptive diagram of the camera?

Post a reply to this message

"gregjohn" <pte### [at] yahoocom> wrote:
> I want complete control of the screen. For example, I want to be able to place a
> sphere at the corner of the generated image, no matter what the pixel size or
> ratio of the image, no matter the angle (however it's defined).

Been there, did that:

http://www.tc-rtc.co.uk/imagenewdisplay/stills/index164.html

The coffee spill in this shot is a blob object, with the individual elements
"sputtered" from the camera location, and covering no more than the actually
visible area (plus some "overscan" for the focal blur).

The core of that code is as follows:

#include "math.inc"
#include "transforms.inc"

#declare camera_location        = <6,5,6>;
#declare camera_angle           = 60;
#declare camera_look_at         = <0,1.5,0>;
#declare camera_focus_at        = <0.3,1.0,0.3>;
#declare camera_look_at_level   = (x+z)*camera_look_at + y*camera_location;
#declare camera_rotate          =-VAngleD(camera_look_at_level -
camera_location, z);
#declare camera_tilt            = VAngleD(camera_look_at_level -
camera_location, camera_look_at - camera_location);
#declare camera_transform       = transform { rotate x*camera_tilt rotate
y*camera_rotate }
#declare camera_true_right      = vtransform(x,
camera_transform);
#declare camera_true_up         = vtransform(y*image_height/image_width,
camera_transform);
#declare camera_true_direction  = vtransform(z*0.5/tand(camera_angle/2),
camera_transform);
#declare base_plane = plane { y, 0 }
#macro VCamera(xScreen,yScreen)     (camera_true_direction +
(xScreen/image_width-0.5)*camera_true_right +
(yScreen/image_height-0.5)*camera_true_up) #end
#macro VTrace(obj,xScreen,yScreen)
trace(obj,camera_location,VCamera(xScreen,yScreen)) #end

camera{
  perspective
  location  camera_location
  right     x
  up        y*image_height/image_width
  angle     camera_angle
  look_at   camera_look_at
}

The VTrace() macro traces a ray from the camera for a particular point on the
screen.


> I've got a way to do this using an obtuse use of the right vector.  It works
> perfectly for the camera in the default location. If I want to look somewhere
> else, I can simply apply a transform to both the camera and the object.  Using
> the formula in that is in the docs doesn't work immediately in my code.  I
> suspect the docs aren't completely telling us how the camera actually works--
> that image sure as heck doesn't.

The image in the docs sure as heck *DOES* - provided you use the "correct"
parameters that are expected to be used for camera control these days:

- use the up/right/direction vectors to define what axis is to be projected to
the vertical on the image (up), what the aspect ratio of your shot will be (up
& right), and whether you have a "left-" or "right-handed" co-ordinate system
(up & right & direction); that and *NO MORE*. AFAIK only the relative length of
these vectors matters except for the "up" vector which needs to point in a
suitable direction (the absolute length still doesn't matter) and that they
should be perpendicular to each other matching your desired "handedness".

- use location and look_at to define where the camera is placed (location) and
what direction it is facing (location & look_at).

- use angle to define the camera's opening angle (left to right).

I took *all* information for the above code from the online doc, *particularly*
the image you're ranting against. That plus some generic knowledge about vector
math.


> There are a bunch of parameters that can be
> played with, but I don't know how the camera actually WORKS.

If you want it to work (and match the diagram in the docs), use the above
schema.

If you want to fully understand what each parameter does when used in a
particular order (beyond what the docs disclose if you read them carefully),
dig through the code...

Post a reply to this message

> Q: Has anyone seen a more descriptive diagram of the camera?

This is how I look at it... the up, right, and direction vectors all
really share the same origin, but they are used to describe the
viewing plane that the direction vector points at the middle of.

Then you can view the other camera keywords as modifiers,
they modify the up, right, and direction vectors in some way.

Location translates the vectors.
Look_at rotates the vectors to point somewhere.
The sky vector changes how the rotation happens.
Angle changes the length of the direction vector to
fit a given horizontal viewing angle.

It's a trigonometry problem to figure out the exact pixel of
some location in the scene with a given camera. You
know the vector from the camera to the object, and
you know the location of the viewing plane, so you just
figure out the angles between the direction vector and
that.

// camera diagram
#include "colors.inc"

camera {
  location  <2.5, 1, -2.5>
  direction z
  up y
  right     x*image_width/image_height
  look_at   <0, 0.25,  1>
  angle 32
}

background {White}

light_source {
  <0, 0, 0>            
  color rgb <1, 1, 1> 
  translate <30, 30, -30>
}

#macro Arrow(A B P)
union {  
  #local _vc = vnormalize( B-A )*0.5;
  #if (0.5 > vlength(B-A)/2)
    #local _vc = vnormalize( B-A )*vlength(B-A)*0.5;
  #end 
  cylinder { A, B-_vc, 0.02}
  cone { B - _vc, 0.04, B, 0}
  pigment{P} 
} 
#end

// viewing plane
polygon {4,
   <-0.5*1.33,0.5,1>,<0.5*1.33,0.5,1>,
   <0.5*1.33,-0.5,1>,<-0.5*1.33,-0.5,1>
   pigment{Blue transmit 0.9}
}

// the direction vector
Arrow(<0,0,0>,<0,0,1>,Yellow)
text {ttf "timrom.ttf", "Direction", 0.01,0 
   scale <0.08,0.1,1>
   translate <0.1,0.04,0>
   rotate <0,-90,0>
   pigment {Yellow}
}

// the right vector
Arrow(<0,0,0>,<1.33,0,0>,Red)
Arrow(<-0.5*1.33,0,1>,<0.5*1.33,0,1>,pigment{Red transmit 0.8})
text {ttf "timrom.ttf", "Right", 0.01,0 
   scale <0.08,0.1,1>
   translate <0.1,0.04,0>
   pigment {Red}
}

// the up vector
Arrow(<0,0,0>,<0,1,0>,Blue)
Arrow(<0,-0.5,1>,<0,0.5,1>,pigment{Blue transmit 0.8})
text {ttf "timrom.ttf", "Up", 0.01,0 
   scale <0.08,0.1,1>
   translate <0.1,0.05,0>
   rotate <0,0,90>
   pigment {Blue}
}

Post a reply to this message

"Tim Attwood" <tim### [at] anti-spamcomcastnet> wrote:
> > Q: Has anyone seen a more descriptive diagram of the camera?
>
> This is how I look at it... the up, right, and direction vectors all
> really share the same origin, but they are used to describe the
> viewing plane that the direction vector points at the middle of.
>

Thanks greatly.  Starting with a knowledge of the importance of just those three
terms, I came up with the answer: the direction defines half the distance to the
plane at which objects will be seen at up and right distances from the origin.
That information is power.

The diagram in the docs is great for teaching newbies and it does not lie. But
it has useless units "+0.5, -0.5" and provides no information about what
direction does.

Anyway, here's the code inspired by Tim's own.

#include "colors.inc"
#declare iwih=image_width/image_height;
#declare azee=0.0001+100*clock;

camera {
  direction z*azee
  up y
  right     x*image_width/image_height
}

background {White}

light_source {
  <0, 0, 0>
  color rgb <1, 1, 1>
  translate <30, 30, -30>
  shadowless
}

sphere{<-iwih,-1,0>,0.05 translate 2*azee*z }
sphere{<iwih,1,0>,0.05 translate 2*azee*z}
box{<-iwih,-1,0>,<iwih,1,0.001>
        translate 2*z*azee*1.01
        pigment{Red}}

Post a reply to this message

gregjohn wrote:

> I want complete control of the screen. For example, I want to be able to place a
> sphere at the corner of the generated image, no matter what the pixel size or
> ratio of the image, no matter the angle (however it's defined).

Would screen.inc be adequate for your purpose?

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> wrote:
> gregjohn wrote:
>
> > I want complete control of the screen. For example, I want to be able to place a
> > sphere at the corner of the generated image, no matter what the pixel size or
> > ratio of the image, no matter the angle (however it's defined).
>
> Would screen.inc be adequate for your purpose?

Thanks for the reminder, but I think I need to have more control of the entire
screen, not just an ability to have one object placed in front of the camera
for me.

Applications:
i) I want to make a plotting macro.
ii) Crowd scenes.  I think John vanSickle once mentioned making huge crowd
scenes where you only place objects in the scene in places the camera is
looking.

Forevermore, I'm going to start of my scenes with:

#declare iwih=image_width/image_height;
#declare camang=45 // or whatever
#declare azee=0.5*iwih/tan(camang/2*pi/180);
camera {
  direction z*azee
  up y
  right     x*image_width/image_height
 }

box{
<-iwih/2+0.01,-1/2+0.01,0>,<iwih/2-0.01,1/2-0.01,0.001>
 translate z*azee     pigment{Red+Green/4} finish{ambient .1}}

Post a reply to this message

"gregjohn" <pte### [at] yahoocom> schreef in bericht 
news:web.49adf5ab78557ac434d207310@news.povray.org...
> ii) Crowd scenes.  I think John vanSickle once mentioned making huge crowd
> scenes where you only place objects in the scene in places the camera is
> looking.
>
Sorry for coming across this post so late. I use the following code to do 
just that. In order to close fit the Screen when using CamAng, you can 
fine-tune with CamZoom:

camera {
  location  CamLoc
  sky       CamSky
  up        CamSky
  direction z*CamZoom
  right     x*AspectRatio
  angle     CamAng
  look_at   CamEye
}

#end

// --------------------------------------
// visibility test code by Gilles Tran,
// derived from work by
// John Van Sickle and Christoph Hormann
// --------------------------------------
#declare CamD=vnormalize(CamEye-CamLoc);         // direction of camera view
#declare CamR=vnormalize(vcross(CamSky,CamD));   // to the right
#declare CamU=vnormalize(vcross(CamD,CamR));     // camera up

#declare Screen= // pseudo screen to test the visibility of an object
mesh{
  triangle {0, x, x+y}
  triangle {0, y, x+y}
  translate -0.5*(x+y)
  scale <AspectRatio, 1, 1>
  translate CamZoom*z
  matrix < CamR.x,  CamR.y,  CamR.z,
           CamU.x,  CamU.y,  CamU.z,
           CamD.x,  CamD.y,  CamD.z,
           CamLoc.x,CamLoc.y,CamLoc.z >
}
//Set SeeScreen on to test the pseudo screen
#if (SeeScreen)
  object{Screen pigment{rgbf<1,0,0,0.9>} }
#end

#macro IsObjectVisible(PosObject)
// this macro tests the position of the object against the pseudo screen
  #local Norm1 = <0, 0, 0>;
  #local PosTemp= trace (Screen, PosObject, -PosObject+CamLoc, Norm1);
  #if (vlength(Norm1)!=0 )
    true;
  #else
    false;
  #end
#end



Thomas

Post a reply to this message