Starting with location, look_at, angle and sky, I perform the following 
operations:

//--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

#declare Camera_Location = <25.000000,15.000000,-33.000000>;
#declare Camera_Look_At = <2.000000,2.000000,0.000000>;
#declare Camera_Angle = 70.000000;
// should be able to set this to false as well
#declare Camera_Orthographic = true;

#local CamL = Camera_Location;
#local CamD = vnormalize(Camera_Look_At - CamL);
#local CamR = vnormalize(vcross(Camera_Sky, CamD));
#local CamU = vnormalize(vcross(CamD, CamR));
#local CamW = vlength(Camera_Look_At - CamL);

#if (Camera_Orthographic = true)
	#local CamR = CamR * CamW;
	#local CamU = CamU * CamW;
#end

#declare Camera_Zoom		= 1/2/tand(Camera_Angle/2) * Camera_Aspect_Ratio;
#declare Camera_Direction	= CamD * Camera_Zoom;
#declare Camera_Right		= CamR * Camera_Aspect_Ratio;
#declare Camera_Up			= CamU;

//--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

The code calculates the values of the camera's direction, right and up.

My question is, how do I do the inverse? I.e. starting with location, 
direction, right and up, how do I calculate look_at, angle and sky? It 
seems like pretty simple algebra but I have been hitting my head against 
the wall trying to figure it out.

Thanks.


Michael

Post a reply to this message

On 6/23/2019 6:03 PM, Mike Horvath wrote:
> Starting with location, look_at, angle and sky, I perform the following 
> operations:
> 
> //--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
> 
> #declare Camera_Location = <25.000000,15.000000,-33.000000>;
> #declare Camera_Look_At = <2.000000,2.000000,0.000000>;
> #declare Camera_Angle = 70.000000;
> // should be able to set this to false as well
> #declare Camera_Orthographic = true;
> 
> #local CamL = Camera_Location;
> #local CamD = vnormalize(Camera_Look_At - CamL);
> #local CamR = vnormalize(vcross(Camera_Sky, CamD));
> #local CamU = vnormalize(vcross(CamD, CamR));
> #local CamW = vlength(Camera_Look_At - CamL);
> 
> #if (Camera_Orthographic = true)
>      #local CamR = CamR * CamW;
>      #local CamU = CamU * CamW;
> #end
> 
> #declare Camera_Zoom        = 1/2/tand(Camera_Angle/2) * 
> Camera_Aspect_Ratio;
> #declare Camera_Direction    = CamD * Camera_Zoom;
> #declare Camera_Right        = CamR * Camera_Aspect_Ratio;
> #declare Camera_Up            = CamU;
> 
> //--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
> 
> The code calculates the values of the camera's direction, right and up.
> 
> My question is, how do I do the inverse? I.e. starting with location, 
> direction, right and up, how do I calculate look_at, angle and sky? It 
> seems like pretty simple algebra but I have been hitting my head against 
> the wall trying to figure it out.
> 
> Thanks.
> 
> 
> Michael


Disregard. I got it working.

Michael

Post a reply to this message

Starting with location, direction, up and right I was able to figure out 
how to calculate the angle; however I had trouble with look_at. I could 
get a look_at that worked well enough to get an accurate render, but it 
was was always normalized between 0 and 1 unless the camera was 
orthographic. See the "Updated screen.inc" thread in p.t.s-f.


Michael

Post a reply to this message

Mike Horvath <mik### [at] gmailcom> wrote:
> Starting with location, direction, up and right I was able to figure out
> how to calculate the angle; however I had trouble with look_at. I could
> get a look_at that worked well enough to get an accurate render, but it
> was was always normalized between 0 and 1 unless the camera was
> orthographic. See the "Updated screen.inc" thread in p.t.s-f.
>
>
> Michael

Right, because it's not something that's going always going to be static and
untouched.

"When you specify the angle, POV-Ray adjusts the length of the direction vector
accordingly. The formula used is direction_length = 0.5 * right_length /
tan(angle / 2) where right_length is the length of the right vector. You should
therefore specify the direction and right vectors before the angle keyword. The
right vector is explained in the next section."

So unless you're going to store the "original" length of the direction vector,
which is going to be derived from look_at and location, you can only ever
backtrack to a normalized vector.

If it's a stored value, say, a scalar multiplier, then you can just multiply the
direction by that and you're back to "where you started". (assuming that's how
it all got defined)

It's like integrating - you lose the constants when you differentiate, and so
when you integrate, you just add "some constant C" into your equation.
So when you do your "reverse" calculations, all you can say for sure is "the
direction is <x, y, z> times some scalar multiplier C.   Which may or may not be
important.

Post a reply to this message

On 6/25/2019 5:37 PM, Bald Eagle wrote:
> So unless you're going to store the "original" length of the direction vector,
> which is going to be derived from look_at and location, you can only ever
> backtrack to a normalized vector.

Thanks. No, I'm not going to store values.


Michael

Post a reply to this message

Mike Horvath <mik### [at] gmailcom> wrote:
> On 6/25/2019 5:37 PM, Bald Eagle wrote:
> > So unless you're going to store the "original" length of the direction vector,
> > which is going to be derived from look_at and location, you can only ever
> > backtrack to a normalized vector.
>
> Thanks. No, I'm not going to store values.
>
>
> Michael

Why not?   It's done all the time.
For instance:

#ifndef (Screen_Inc_Temp)
#declare Screen_Inc_Temp = version;
#version 3.7;

.....

#version Screen_Inc_Temp;
#end

Post a reply to this message

On 6/26/2019 4:35 PM, Bald Eagle wrote:
> 
> Mike Horvath <mik### [at] gmailcom> wrote:
>> On 6/25/2019 5:37 PM, Bald Eagle wrote:
>>> So unless you're going to store the "original" length of the direction vector,
>>> which is going to be derived from look_at and location, you can only ever
>>> backtrack to a normalized vector.
>>
>> Thanks. No, I'm not going to store values.
>>
>>
>> Michael
> 
> Why not?   It's done all the time.
> For instance:


I am overhauling "screen.inc". The macro has many modes, but it is only 
meant to be called once per scene/render. You would need to run the 
macro multiple times in order to create a variable and retrieve its 
value later on.


Michael

Post a reply to this message

Mike Horvath <mik### [at] gmailcom> wrote:

> I am overhauling "screen.inc". The macro has many modes, but it is only
> meant to be called once per scene/render. You would need to run the
> macro multiple times in order to create a variable and retrieve its
> value later on.

One would presume that normal usage would start with a user declaring a camera
location and look_at.  That gives you both direction and magnitude.

#declare Temp_Direction = whatever;  right at the beginning of the macro.

Just use that stored value to fix your normalized vector before exiting the
macro.
Problem solved.




There are also loops, and #ifndef().

#while (Q) some flag to say that you're done, is undefined, loop back.
you can use #switch / #case / #break to select first pass or second pass code,
if you even needed to do more than a single macro run, which I don't think you'd
need to.

Just saying it's possible, not that it's necessary.

Post a reply to this message