 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3eaae469@news.povray.org> , "Slime" <slm### [at] slimeland com> 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
|
|
| |
| |
|
|
|
|
| |
|
|
