 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Even after using POV-Ray for over 5 years and considering myself an
experienced user, the exact meaning of different camera parameters still
elude me.
Could someone who knows exactly how they work explain in detail?
For example, I fail to deduce the reason why "up -y" flips the image
horizontally.
What is the difference between the 'sky' and the 'up' vectors?
How exactly does 'direction' work?
Do 'angle' and 'direction' work together, or are they mutually exclusive
alternatives to do the same thing (by different way of measuring things)?
That is, if I specify 'direction', does it simply override a previous 'angle'
definition, or does it add something to it instead?
What is the relation (if any) between 'direction' and 'look_at'?
Perhaps 'direction' is a way of defining both 'angle' and 'look_at' with
one single vector?
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The first thing you must understand is the difference between camera
parameters and camera modifiers.
The following are camera parameters:
location <Location> | right <Right> | up <Up> |
direction <Direction> | sky <Sky>
They set up the camera as shown in section 6.4.1 of the documentation
(please ignore the angle and look_at vectors in that diagram). If you use
only these parameters, the camera will turn out exactly as that picture
shows. Note that the length of these vectors is important (a longer
direction will cause the camera to zoom in more, for instance). Also note
that, at this point, the sky vector is meaningless and has absolutely no
effect.
After these vectors have been specified (or, if they're not specified, after
they take their default value), the following camera *modifiers* *change*
them:
angle HORIZONTAL [VERTICAL] | look_at <Look_At> |
blur_samples Num_of_Samples | aperture Size |
focal_point <Point> | confidence Blur_Confidence |
variance Blur_Variance | NORMAL | TRANSFORMATION
in the following ways:
- The angle keyword will change the length of the direction vector, based on
the formula direction_length = 0.5 * right_length / tan(angle / 2).
- the look_at vector is applied in the following manner: the direction is
changed to face towards the look_at vector, the right vector is changed to
be perpendicular to [the plane created by the vectors (look_at-location) and
(sky-location)], and the up vector is made to remain along that plane. This
is the most intuitive behavior, which lets you specify where the camera is
looking at. The sky vector is used at this point to determine how much the
camera is "rolled" (so that it knows which direction is "up").
- the rest of the settings apply to focal blur and other camera features.
At this point, once all of the modifiers have been applied, transformations
(rotation, translation, etc) will be applied to the camera.
So now, to answer your specific questions:
> For example, I fail to deduce the reason why "up -y" flips the image
> horizontally.
It probably has something to do with the order in which you specified
keywords or something. Remember that the keywords are applied in the order
described above, regardless of what order they're placed in. Chances are,
because of the use of the look_at vector, after inverting the camera
vertically, it flipped right back up because of the sky vector when look_at
was applied. If you want "up" to be -y, use "sky -y".
> What is the difference between the 'sky' and the 'up' vectors?
The up vector is a more precise part of the camera's definition, while the
sky vector is only used to determine the general direction of the up vector
when look_at is applied.
> Do 'angle' and 'direction' work together, or are they mutually exclusive
> alternatives to do the same thing (by different way of measuring things)?
> That is, if I specify 'direction', does it simply override a previous
'angle'
> definition, or does it add something to it instead?
'angle' changes the length of 'direction' after the camera has been set up.
'direction' will always be applied first (and multiple settings of it
override previous settings, I believe), so it is impossible to override
'angle' with 'direction' - the opposite always happens.
> What is the relation (if any) between 'direction' and 'look_at'?
The look_at keyword modifies the direction of the 'direction', 'up', and
'right' vectors after their initial values have been set. In the end, the
direction vector, based at the location vector, will point towards the
look_at vector, but will maintain its length.
> Perhaps 'direction' is a way of defining both 'angle' and 'look_at' with
> one single vector?
direction is the original setting, angle and look_at modify it.
I hope this helps you. It took me a *lot* of time and experience to figure
this out, so I don't blame you for not knowing. Perhaps an entry in the VFAQ
would be a good idea?
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ok, I wrote this from memory, with no pov nor doc to check it. I write
only about the perspective camera. Some things apply to other camera
types, other do not. (Very helpful, isn't it ?)
Perspective camera uses perspective projection. To understand it, the
easiest is to go back to a real-world explanation : to paint as the eye
see, paint what you see through a pane of glass on the pane itself.
That is, from the eye, trace a ray to any point you wish to trace and
then colour the glass at the intersection of the ray and the pane.
location is the eye, the point from which all rays pass. up, right and
direction define the virtual glass pane through and onto which pov
traces, and which is then mapped onto the +w,+h window.
up and right define a parallelogram, most usually a rectangle (other
shapes distort the picture). It's centre is placed at direction. up is
mapped to +h and right to +w.
Usually, up, right and direction are orthogonal. If up and right aren't,
it skews the image. If direction isn't orthogonal with up and right,
while up and right are orthogonal, the effect is as if you traced a
rectangular part of a larger trace. (There is a standard include files
that does just this, I suppose it must be in a Camera directory.)
Now, look_at rotates the camera (the up, right, direction trihedron)
around the origin to align direction with look_at. The camera is first
rotated around the sky axis then around an axis normal to both sky and
the new direction.
angle is the angle from both end of right (when it is centred around
direction) to location. Changing angle is akin to modifying direction's
length.
location, right, up and direction define the camera. sky, look_at and
angle are tools to manipulate these fundamental constituents.
Does this help?
Povingly,
Philippe
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime <slm### [at] slimeland com> wrote:
> Chances are,
> because of the use of the look_at vector, after inverting the camera
> vertically, it flipped right back up because of the sky vector when look_at
> was applied.
So using "up -y right -x*4/3 look_at whatever" is exactly identical to
"up y right x*4/3 look_at whatever"?
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> So using "up -y right -x*4/3 look_at whatever" is exactly identical to
> "up y right x*4/3 look_at whatever"?
If my understanding is correct, then yes, those two settings will result in
an identical camera (although they will do so in different ways internally).
If you leave out the look_at statement, they will result in different
cameras.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
> - the look_at vector is applied in the following manner: the direction is
> changed to face towards the look_at vector, the right vector is changed to
> be perpendicular to [the plane created by the vectors (look_at-location) and
> (sky-location)], and the up vector is made to remain along that plane. This
> is the most intuitive behavior, which lets you specify where the camera is
> looking at. The sky vector is used at this point to determine how much the
> camera is "rolled" (so that it knows which direction is "up").
Gee, I had totally forgotten that look_at straigthens the up and right
vectors.
Thanks!
Now I remember also to wonder : why ? I believe it is the only case
where Pov tries to 'smartly' correct what the user specifies... and
destroy my careful camera shearing. (BTW and IIRC, one need to disable
vista buffers to use camera shearing.)
Povingly,
Philippe
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3ea8f217@news.povray.org> , Philippe Debar <phd### [at] wanadoobe>
wrote:
> Now I remember also to wonder : why ? I believe it is the only case
> where Pov tries to 'smartly' correct what the user specifies... and
> destroy my careful camera shearing. (BTW and IIRC, one need to disable
> vista buffers to use camera shearing.)
It is a necessity because "look_at" is just a simplified way to modify those
vectors. And it is well documented in 3.5 as well...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> It is a necessity because "look_at" is just a simplified way to modify those
> vectors.
Yes, but why ? To my non-programmer's ears, it does not sound more
complicated to rotate the vectors instead of defining new ones. But I
suppose that even a tad more complicated would imply a noticeable
slowdown if the function is called for each ray. Right ?
> And it is well documented in 3.5 as well...
As I wrote earlier, I was posting from memory without access to pov nor
the doc. Now I checked some, but I did not find any reference of look_at
redefining perpendicular up and right. However, I found some references
that could be corrected because they talk about a rotation of the
camera, which is not what is happening - although I agree it is the
easiest explanation, as few user would specify non-normal
direction/right/up on purpose.
---
3.1.3
Also look_at <0,1,2> rotates the camera to point at the coordinates
<0,1,2>.
6.4.1.1
The look_at vector tells POV-Ray to pan and tilt the camera until it is
looking at the specified x, y, z coordinates.
6.4.1.2
Normally POV-Ray pans left or right by rotating about the y-axis until
it lines up with the look_at point and then tilts straight up or down
until the point is met exactly.
[...] Then it uses the sky vector as the axis of rotation left or right
and then to tilt up or down in line with the sky until pointing at the
look_at point.
[...]
The sky vector does nothing on its own. It only modifies the way the
look_at vector turns the camera. The default value is sky<0,1,0>.
6.4.1.5
The primary purpose of the up and right vectors is to tell POV-Ray the
relative height and width of the view screen.
[...]
In the default perspective camera, these two vectors also define the
initial plane of the view screen before moving it with the look_at or
rotate vectors.
----
BTW, is anybody up to patching pov for using vista buffers with
non-perpendicular direction/right/up ? I guess it should not be too
hard, but what do I know ?
Povingly,
Philippe
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Gee, I had totally forgotten that look_at straigthens the up and right
> vectors.
Oh, wait. I hadn't thought about the case where the up and right vectors
weren't already perpendicular. *Does* it straighten them out in this case,
or does it align the right vector as I described, or does it align the up
vector as I described?
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3eaa9156@news.povray.org> , Philippe Debar <phd### [at] wanadoobe>
wrote:
> Yes, but why ? To my non-programmer's ears, it does not sound more
> complicated to rotate the vectors instead of defining new ones.
It is rather complicated, but without it there would be cases for which
there is more than one solution which way the camera could be pointing.
Further, the look_at vector is of no use when actually creating camera rays
because it does not contain enough information on its own together with the
location. That is why up, right and sky have defaults.
The key about understanding, or even trying to understand how the various
camera parameters interact (and have to interact to work together at all in
certain cases), is to understand that many are redundant ways to specify the
same information:
All you need is the up, right and direction vectors to create every possible
perspective camera specification that uses a combination of up, right,
direction, look_at, angle, sky and location. To make it even more
complicated, other camera types need to make use only of certain aspects of
these parameters (i.e. the vector length), or they need additional
parameters (like the spherical camera).
So don't worry - without seeing the source code in action step by step, I
would never have understood what exactly is happening and why.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3eaae469@news.povray.org> , "Slime" <slm### [at] slimelandcom> wrote:
> Oh, wait. I hadn't thought about the case where the up and right vectors
> weren't already perpendicular. *Does* it straighten them out in this case,
> or does it align the right vector as I described, or does it align the up
> vector as I described?
See parse.cpp function Parse_Camera.....
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> It is rather complicated, but without it there would be cases for which
> there is more than one solution which way the camera could be pointing.
I suppose this is when look_at lines up with sky. I guess new rules of
rotation could be defined, and as they'll be arbitrary, there is the
risk of a small war about which rule is the true and only way. As most
advanced user can probably set up their direction/right/up vectors
without resorting to sky/look_at, I understand it could be considered
wasteful.
> Further, the look_at vector is of no use when actually creating camera rays
> because it does not contain enough information on its own together with the
> location. That is why up, right and sky have defaults.
>
> The key about understanding, or even trying to understand how the various
> camera parameters interact (and have to interact to work together at all in
> certain cases), is to understand that many are redundant ways to specify the
> same information:
>
> All you need is the up, right and direction vectors to create every possible
> perspective camera specification that uses a combination of up, right,
> direction, look_at, angle, sky and location.
I understand that. And I guess that all transformations boils down to
changing these vectors. Oh, and location too.
> To make it even more
> complicated, other camera types need to make use only of certain aspects of
> these parameters (i.e. the vector length), or they need additional
> parameters (like the spherical camera).
>
> So don't worry - without seeing the source code in action step by step, I
> would never have understood what exactly is happening and why.
I just tried to read the Parse_Camera function, but I know too little
about C and how parsers work to understand precisely what it is doing
:'-(. I'll do some experiments in sdl to further my understanding.
Many thanks for your answers,
Povingly,
Philippe
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
> Oh, wait. I hadn't thought about the case where the up and right
> vectors
> weren't already perpendicular. *Does* it straighten them out in this
> case,
> or does it align the right vector as I described, or does it align the
> up
> vector as I described?
I just did some testing:
* look_at straightens all vectors (even when direction-location = look_at).
* sky alone has no effect.
* I can't figure what really happens when right, sky and look_at are
aligned - but I am under the impression this defines a degenerated
camera that traces only one "point" (not pixel, one ray only). Not very
important.
I tried to match POV behavior in SDL - this is not thoroughly tested but
it seems to work quite nicely.
// --- BEGIN SDL ---
// Trying to reproduce POV original sky/look_at behavior in SDL
camera{
// Declare camera parameters
#local Camera_location = <0,.1,-3> ;
#local Camera_direction = 1*vnormalize(<0,0,1>) ;
#local Camera_up = 1*vnormalize(<0,1,2>) ;
#local Camera_right = 1*vnormalize(<1,0,0>) ;
#local Camera_sky = 1*vnormalize(<0,1,0>) ;
#local Camera_look_at = <-.5,1,.5> ;
#if (0) // choose between POV coded behaviour and SDL behaviour
location Camera_location
direction Camera_direction
up Camera_up
right Camera_right
sky Camera_sky
look_at Camera_look_at
#else
// new look_at to account for location
#declare New_look_at=Camera_look_at-Camera_location ;
// examine handedness
#declare Camera_handedness = vdot( Camera_direction, vcross(
Camera_right, Camera_up ) );
#declare Camera_handedness = Camera_handedness / abs(
Camera_handedness );
// new direction is look_at, conserve length (=zoom) and orientation
#declare New_direction = vnormalize( New_look_at) * vlength(
Camera_direction );
// if look_at and sky are aligned
#if (vlength(vcross(New_look_at, Camera_sky))<1e-6)
// do nothing ;
#declare New_right = Camera_right ;
#else
// else, new right is normal to the look_at-sky plane, conserve
// length and orientation
#declare New_right= vnormalize( vcross ( Camera_sky, New_look_at
) ) * vlength( Camera_right ) * Camera_handedness;
#end
// new up is normal to the look_at-right plane, conserve length
// and orientation
#declare New_up = vnormalize ( vcross ( New_look_at, New_right ) )
* vlength( Camera_up )* Camera_handedness;
// look_at and New_right can't be aligned
location Camera_location
direction New_direction
up New_up
right New_right
#end
}
// --- END SDL ---
Povingly,
Philippe
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3eac4548$1@news.povray.org> , Philippe Debar
<phd### [at] wanadoobe> wrote:
> I tried to match POV behavior in SDL - this is not thoroughly tested but
> it seems to work quite nicely.
No, the source code is really much more correct. You cannot come to a
working reproduction of what happens without taking it from the source code.
And no knowledge about parsers is required to understand it. Only a tiny
bit of C.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>>I tried to match POV behavior in SDL - this is not thoroughly tested but
>>it seems to work quite nicely.
>
>
> No, the source code is really much more correct.
I have no doubt about that ;-)
> You cannot come to a
> working reproduction of what happens without taking it from the
source code.
It surely would be quicker if I understood it. However, while my way is
surely slower (from a knowledgeable programmer p.o.v., quicker for me),
I don't think it is impossible.
Up to now, for every case I tested, the behaviour was matched. I'll
welcome any case where my code fails and I'll try to correct it. It just
seems to be the easiest way to understand (and explain) what is
happening (as a result, not as a process).
> And no knowledge about parsers is required to understand it. Only a tiny
> bit of C.
I must say I do not know where to begin. Maybe I'll borrow a book from
my father or my brother (if they let me).
Povingly,
Philippe
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> No, the source code is really much more correct. You cannot come to a
> working reproduction of what happens without taking it from the source code.
> And no knowledge about parsers is required to understand it. Only a tiny
> bit of C.
OK, I got back to Parse_Camera, gritted my teeth and tried to translate
the look_at mechanism for perspective camera to POV's SDL. I think I
succeeded ;-) Here's the code (more rants after that) :
// --- BEGIN SDL ---
// Reproducing POV original sky/look_at behavior in SDL
// for perspective camera only
camera{
#local Cam_location = 1*<0,.1,-3> ;
#local Cam_direction = 1*vnormalize(<0,0,1>) ;
#local Cam_up = 1*vnormalize(<0,1,0>) ;
#local Cam_right = 1*vnormalize(<1,0,0>) ;
#local Cam_sky = 1*vnormalize(<0,1,0>) ;
#local Cam_look_at = <-.5,1,.5> ;
//#local Cam_angle = 30;
#local Simulate_POV_look_at = on ;
#if (Simulate_POV_look_at)
#ifndef(Cam_location ) #declare Cam_location = 0 ; #end
#ifndef(Cam_direction) #declare Cam_direction = z ; #end
#ifndef(Cam_right ) #declare Cam_right = 1.33*x ; #end
#ifndef(Cam_up ) #declare Cam_up = y ; #end
#ifndef(Cam_sky ) #declare Cam_sky = y ; #end
#ifdef(Cam_angle)
#if(Cam_angle>=180) #error "Viewing angle has to be smaller than
180 degrees." #end
#if(Cam_angle<0) #error "Negative viewing angle." #end
#declare Cam_direction =
vnormalize(Cam_direction)*vlength(Cam_right)/ tan(Cam_angle*pi/360)/2;
#end
#ifdef(Cam_look_at)
#declare Cam_direction_length = vlength(Cam_direction) ;
#declare Cam_up_length = vlength(Cam_up) ;
#declare Cam_right_length = vlength(Cam_right) ;
#declare Cam_tempv = vcross(Cam_up, Cam_direction) ;
#declare Cam_Handedness = vdot(Cam_tempv, Cam_right) ;
#declare Cam_direction=Cam_look_at-Cam_location ;
#if(vlength(Cam_direction)<1e-10) #error "Camera location and
look_at point must be different." #end
#declare Cam_direction=vnormalize(Cam_direction) ;
#declare Cam_tempv= vcross(Cam_sky, Cam_direction) ;
#if (vlength(Cam_tempv)>1e-10) #declare
Cam_right=vnormalize(Cam_tempv) ; #end
#declare Cam_up=vcross(Cam_direction, Cam_right)* Cam_up_length;
// works bcs right and direction are normalized
#declare Cam_direction=Cam_direction*Cam_direction_length ;
#declare Cam_right = Cam_right * ( Cam_Handedness >0 ?
Cam_right_length : -Cam_right_length ) ;
#end
#end
#ifdef(Cam_location ) location Cam_location #end
#ifdef(Cam_direction) direction Cam_direction #end
#ifdef(Cam_right ) up Cam_up #end
#ifdef(Cam_up ) right Cam_right #end
#ifdef(Cam_sky ) sky Cam_sky #end
#ifdef(Cam_angle ) angle Cam_angle #end
#ifdef(Cam_look_at ) look_at Cam_look_at #end
}
// --- END SDL ---
I adapted some of it to my taste, I hope I did not fucked anything up.
BTW, I found that POV produces not-very-helpful errors if one uses either :
* right 0
* up 0
* direction 0
The error is "Slab Building Error: Singular matrix in MInvers."
If you specify either
* sky 0
* sky = look_at - location
& use look_at
& you have vista buffers enabled (default), you'll get an somehow
erroneous error : "Slab Building Error: Cannot use non-perpendicular
camera vectors with vista buffer." - what happens is that the right
vector can't be computed so is left with its original value, while
direction and up are modified, effectively defining a sheared camera
inside POV while the user never specified such a thing.
What I do not understand is that while I can get this behavior by using
sky = look_at - location, I am unable to reproduce it using look_at =
sky + location, which I deem much more probable to happen in real use.
Anyway, I hope the code can help people understand how the perspective
camera's look_at is working. (BTW it seems to be 3.5 specific, but that
is not documented in "2.6.14 Changed features that may 'break' old
scenes").
Povingly,
Philippe
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
