 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3ea8f217@news.povray.org> , Philippe Debar <phd### [at] wanadoo be>
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
|
|
| |
| |
|
|
|
|
| |
|
|
