Vector to yaw and pitch - Google Earth Pro - camera control

[Blaxxun]

Hello ladys and gentlemen,

I try to write a little tool for google earth pro.

I need to be able to control the camera yaw and pitch with a "look-at" vector.

Yaw is actually working already so far, but after reading dozens of articles about this topic i just cant figure out why the Pitch is not working.

Maybe someone here is better in this kind of math and stuff than me.

The 2 includes are from the "Advanced Math UDF 1.8".

In Google Earth's settings i recommend to set the navigation speed to 100%.

Thanks !

 

expandcollapse popup

#include <Vector.au3>
#include <Trigonometric.au3>

If Not WinExists("Google Earth Pro") Then Exit

Global $P = @DesktopDir & "\IntPos.kml" ;    File Path


Global $Rad = 57.2957795130823 ; Radians
;Längengrad  = Longitude    = X
;Breitengrad = Latitude        = Y

$CamPos = Vector(-5.4, 21.5, 15)
$CamTar = Vector(-5.4, 21.501, 10)


For $NR = 0 To 30 Step 6

    ;$CamTar[0] = $CamTar[0] - ($NR / 100000) ;                        Interest X
    ;$CamTar[1] = $CamTar[1] + ($NR / 100000) ;                        Interest Y
    $CamTar[2] = $CamTar[2] + $NR ;                                    Interest Z


    $CamDir = VectorNormalize(VectorSubtract($CamPos, $CamTar))

    $dx = $CamDir[0]
    $dy = $CamDir[1]
    $dz = $CamDir[2]

    ;$Pitch = Atan2(Sqrt($dx ^ 2 + $dy ^ 2), $dz) ;                    Vertikal 0.0009
    ;$Pitch = Atan2($dz, Sqrt($dx ^ 2 + $dy ^ 2)) ;                    Vertikal 89.99
    ;$Pitch = Atan2(Sqrt($dx ^ 2 + $dz ^ 2), $dy) ;                    Vertikal 90.00
    ;$Pitch = ATan((Sqrt(($dx ^ 2) + ($dy ^ 2))) / $dz * -1) ;         Vertikal 0.0009

    $radius = Sqrt(($dx ^ 2) + ($dy ^ 2) + ($dz ^ 2))
    $Pitch = ACos($dz/$radius)

    $Yawww = ATan2($dx, $dy) ;                                        Horizontal

    ;Horizontal    = Azimuth φ        = Yaw
    ;Vertikal    = Inclination θ    = Pitch


    $Pitch = ($Pitch * $Rad) - 90
    $Yawww = ($Yawww * $Rad) + 180

    ConsoleWrite("Pitch : " & $Pitch & @LF) ;                         Tilt - Vertikal
    ConsoleWrite("Yaw   : " & $Yawww & @LF) ;                         Head - Horizontal


    KML($CamPos[0], $CamPos[1], $CamPos[2], $Yawww, $Pitch, 0, $CamTar[0], $CamTar[1], $CamTar[2])
    Go(1000)

Next


Func KML($long, $lat, $alt, $head, $tilt, $roll, $longP, $latP, $altP)

    ; Open File
    Local $H = FileOpen($P, 2) ; Open Overwrite
    ; Header
    FileWriteLine($H, '<?xml version="1.0" encoding="UTF-8"?>')
    FileWriteLine($H, '<kml xmlns="http://www.opengis.net/kml/2.2" xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns:kml="http://www.opengis.net/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom">')
    FileWriteLine($H, '<Document>')
    FileWriteLine($H, '<name>IntPos.kml</name>')
    ; Camera
    FileWriteLine($H, '<Camera>')
    FileWriteLine($H, '<longitude>' & $long & '</longitude>')
    FileWriteLine($H, '<latitude>' & $lat & '</latitude>')
    FileWriteLine($H, '<altitude>' & $alt & '</altitude>')
    FileWriteLine($H, '<heading>' & $head & '</heading>')
    FileWriteLine($H, '<tilt>' & $tilt & '</tilt>')
    FileWriteLine($H, '<roll>' & $roll & '</roll>')
    FileWriteLine($H, '<altitudeMode>relativeToSeaFloor</altitudeMode>')
    FileWriteLine($H, '</Camera>')
    ; Pin
    FileWriteLine($H, '<Placemark>')
    FileWriteLine($H, '<name>Pin</name>')
    FileWriteLine($H, '<Point>')
    FileWriteLine($H, '<extrude>1</extrude>')
    FileWriteLine($H, '<altitudeMode>relativeToGround</altitudeMode>')
    FileWriteLine($H, '<drawOrder>1</drawOrder>')
    FileWriteLine($H, '<coordinates>' & $longP & ',' & $latP & ',' & $altP & '</coordinates>')
    FileWriteLine($H, '</Point>')
    FileWriteLine($H, '</Placemark>')
    ;End
    FileWriteLine($H, '</Document>')
    FileWriteLine($H, '</kml>')
    ;Close File
    FileClose($H)

EndFunc   ;==>KML

Func Go($Pause)

    ; Execute KML in Google Earth

    If Not WinExists("Google Earth Pro") Then Exit

    ShellExecute($P)
    Sleep($Pause)

EndFunc   ;==>Go

 

[RTFC]

Hello. Sorry to rain on your parade, but your approach simply won't work, as you're bound to run into gimbal lock issues in Euler space. What you need to do is convert your Euler angles to quaternions, rotate in complex space, then convert back to Euler angles.

[jchd]

Quaternions rule the world, literally!

Also read https://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation to see why quaternions are an elegant and efficient way to handle and compose rotations in 3D space (which aren't commutative any more, contrary to rotations in 2D). See also https://en.wikipedia.org/wiki/Rotation_matrix for a smooth and gentle math-inclined explanation.

As a free bonus quaternions also allow you to introduce scaling and perspective in your 3D space representation.

[RTFC]

@jchd: and octonions may rule the universe.

[jchd]

I don't agree with your pun: the "upper-end" of ℝ-normed-division-algebras (octonions, ) are so unfriendly non-associative guys that their use is considerably limited to a small number of niche domains, whereas quaternions are fair fellows found in almost every technical/scientific/mathematical domain, often surprisingly.

Here again, intuition is misleading. At first, one could naively think that because rotations in 2D can be managed with 2x2 matrices, then 3x3 matrices would do the same nice job in 3D space. It turns out that this isn't the case: "trinions" are inconsistent and we need to jump to 4x4 matrices (equivalent to quaternions). All the same, intuition would make us think that "more is forcibly better", but it again turns out that by loosing fondamental group properties at each step forward we end up with something almost useless, namely . Hopefully, is the end of the series!

Edited February 2, 2019 by jchd

[Xandy]

I'm just happy I learned to pronounce 'quaternions'.

[Blaxxun]

Hello and thanks for your tips.

Iam a 3D Artist and iam well aware of quaternions, euler and 4x4 transformation matrix. (Although i dont know how to program quats and matrix)

But for what i need this "Look-at" camera control, i dont need quaternions or a 4x4 Matrix.

I want to build an automated camera movement program for 3D scanning GE areas with photogrammetry.

Imagine a building. Now imagine an invisible sphere around this building.

The camera moves in full circles from the top to the bottom of this sphere, never leaving the sphere surface.

The cameras interest is always at the center of the sphere.

So since the interest and the camera will never be on the same Z-Axis (or Y for OpenGL) there wont be any funny clipping effects (Euler).

 

So what i have is 2 positions.

1. Camera X,Y,Z

2. Interest X,Y,Z

As i sayd, i can already build a direction vector and i can extract the Yaw from this vector.

But with the Pitch i have problems.

So if anybody has a solution i would be grateful.

I dont need quaternions or a matrix since a vector is enough to extract the Yaw ad Pitch information.

 

@RTFC I do not have yaw and pitch information. I have 2 point positions. Yaw and pitch is what i need since the GE camera works that way. They call it head,tilt and roll. (Roll i dont need).

Edited February 2, 2019 by Blaxxun

[RTFC]

Maybe this will clarify matters.

[Blaxxun]

Thats funny, i was just reading the same flowchart.

I just dont know why the formulas that i tryd are not working.

Those are scattered all over the internet, but the pitch formula seems to refuse working in my case.

Edited February 2, 2019 by Blaxxun

[Blaxxun]

BS deleted.

 

 

 

Edited February 4, 2019 by Blaxxun

[argumentum]

4 hours ago, Blaxxun said:

Autoit cant calculate with large floating point numbers as it seems

CPUs suck at it. Can't you go to integer, by multiplying by 10, `100, etc., then go back to a decimal number if you need to ?

[jchd]

Note that the page cited explicitely mentions quaternions. Also since you mention photogrammetry, they will actually help in representing perspective accurately or make relative measurements of objects.

[jchd]

12 hours ago, Blaxxun said:

A normalized vector can not be bigger than 1 !!

Since when is 9.99999995e-005 > 1 ???

12 hours ago, Blaxxun said:

Autoit cant calculate with large floating point numbers as it seems.

This is plain BS. Please stop spreading FUD.

AutoIt is no more no less capable than any language made running on a IEEE-754-based hardware-software couple (that 's roughly 99.97% of today's personal computers).

Local $aV = [ _
    Vector(0, 0.001, 1), _
    Vector(0, 0.0001, 1), _
    Vector(0, 0.00001, 1), _
    Vector(0, 0.000001, 1), _
    Vector(0, 0.000000123456, 3.1415926) _
]

Local $N
For $v In $aV
    $v = VectorNormalize($v)
    ConsoleWrite(StringFormat("%20.18f\t%20.18f\t%20.18f\r", $v[0], $v[1], $v[2]))
Next

Func Vector($x = 0, $y = 0, $z = 0)
    Local $arr = [$x, $y, $z]
    Return $arr
EndFunc

Func VectorLength($Vec)
    Return Sqrt($Vec[0]^2 + $Vec[1]^2 + $Vec[2]^2)
EndFunc

Func VectorNormalize($Vec)
    Local $len = VectorLength($Vec)
    If $len = 0 Then Return Vector(0, 0, 0)

    Return Vector($Vec[0]/$len, $Vec[1]/$len, $Vec[2]/$len)
EndFunc

 

[Blaxxun]

@argumentum thats a good tip. I have to look into it.

@jchd

I have to admit that i talked BullSh...    Since i found out that the result in the console is a scientific notation.

Sorry for that.

 

The coordinate system in Google Earth provides long,lat and altitude.

It looks like this:

<longitude>10.96324445910746</longitude>
   <latitude>10.81192423951603</latitude>
   <altitude>10.34491166798213</altitude>

Thats 14 digits after the comma.

So when i have a number 0.00000000000001 and i have to get the vector lenght (x^2) then i get

this number: 0.0000000000000000000000000001

thats 28 digits after comma.

$x = 0.00000000000001
$e = $x^2

ConsoleWrite($e & @LF)
ConsoleWrite(StringFormat("%20.28f\t\r", $e))

;Result
;1e-028
;0.0000000000000000000000000001

So the question now is.

Can i still calculate with such small numbers without loosing precision?

Does Autoit's "Variant" handle datatypes like "long double" ?

 

I thought i give C++ a try and wrote a little DLL to see how far i get with it.

With cout.precision(150); and cout << fixed; i was able to see really long numbers. I did not count the digits but im sure it was more than 100 after comma.

However, it kind of works. Horizontal is perfect, but vertical its kinda distance dependent.

It does follow up and down, but is not really centered to the screen. (The camera interest is a Placemark Pin in Google Earth)

I will maybe really give quaternions a shot although iam not grasping them.

C++ code:

#include <iostream>
#include <string>

using namespace std;

double RAD = 57.2957795130823;
struct vec3 { long double x, y, z; };

// Prototypes
long double VectorLength(vec3 V);
vec3 VectorNormalize(vec3 vector);
vec3 VectorSubtract(vec3 v1, vec3 v2);


extern "C" __declspec(dllexport) long double GetYaw(double CamX, double CamY, double CamZ, double TarX, double TarY, double TarZ)
{
	vec3 CamPos;
	vec3 TarPos;

	CamPos.x = CamX;
	CamPos.y = CamY;
	CamPos.z = CamZ;

	TarPos.x = TarX;
	TarPos.y = TarY;
	TarPos.z = TarZ;

	cout.precision(150);

	vec3 CamPosNormal = VectorNormalize(CamPos);
	vec3 TarPosNormal = VectorNormalize(TarPos);
	vec3 CamDirection = VectorSubtract(TarPosNormal, CamPosNormal);

	long double Dx = CamDirection.x;
	long double Dy = CamDirection.y;
	long double Dz = CamDirection.z;

	long double Pitch = asin(Dz) * RAD;
	long double Yaw = atan2(Dx, Dy) * RAD;

	//cout << fixed;
	//cout << "H Yaw:   " << Yaw << endl;
	//cout << "V Pitch: " << Pitch << endl;

	return Yaw;
}


extern "C" __declspec(dllexport) long double GetPitch(double CamX, double CamY, double CamZ, double TarX, double TarY, double TarZ)
{
	vec3 CamPos;
	vec3 TarPos;

	CamPos.x = CamX;
	CamPos.y = CamY;
	CamPos.z = CamZ;

	TarPos.x = TarX;
	TarPos.y = TarY;
	TarPos.z = TarZ;

	cout.precision(150);

	vec3 CamPosNormal = VectorNormalize(CamPos);
	vec3 TarPosNormal = VectorNormalize(TarPos);
	vec3 CamDirection = VectorSubtract(TarPosNormal, CamPosNormal);

	long double Dx = CamDirection.x;
	long double Dy = CamDirection.y;
	long double Dz = CamDirection.z;

	long double Pitch = asin(Dz) * RAD;
	long double Yaw = atan2(Dx, Dy) * RAD;

	//cout << fixed;
	//cout << "H Yaw:   " << Yaw << endl;
	//cout << "V Pitch: " << Pitch << endl;

	return Pitch;
}


long double VectorLength(vec3 V)
{
	return sqrt((V.x * V.x) + (V.y * V.y) + (V.z * V.z));
}

vec3 VectorNormalize(vec3 V)
{
	long double Len = VectorLength(V);

	if (Len == 0)
	{
		V.x = 0; V.y = 0; V.z = 0;
		return V;
	}

	V.x = V.x / Len;
	V.y = V.y / Len;
	V.z = V.z / Len;
	return V;
}

vec3 VectorSubtract(vec3 v1, vec3 v2)
{
	vec3 V;
	V.x = v1.x - v2.x;
	V.y = v1.y - v2.y;
	V.z = v1.z - v2.z;
	return V;
}

 

Autoit "UDF"

#AutoIt3Wrapper_UseX64=y

Func Euler($CamX, $CamY, $CamZ, $TarX, $TarY, $TarZ)

    Local $Yaw = DllCall("LookAt.dll", "double:cdecl", "GetYaw", "double", $CamX, "double", $CamY, "double", $CamZ, "double", $TarX, "double", $TarY, "double", $TarZ)
    Local $Pit = DllCall("LookAt.dll", "double:cdecl", "GetPitch", "double", $CamX, "double", $CamY, "double", $CamZ, "double", $TarX, "double", $TarY, "double", $TarZ)
    Local $Ret[2] = [$Yaw[0], $Pit[0]]
    Return $Ret

EndFunc   ;==>Euler

 

Autoit Main

expandcollapse popup

#AutoIt3Wrapper_UseX64=y
#include <Vector.au3>
#include <LookAt.au3>

If Not WinExists("Google Earth Pro") Then Exit

Global $P = @DesktopDir & "\IntPos.kml" ;   File Path

Global $CamPos = Vector(-75, 40, 20) ;                              Camera Position XYZ
Global $TarPos = Vector(-75, 40.002, 0) ;                           Target Position XYZ


For $NR = 0 To 30 Step 5

    ;$TarPos[0] = $TarPos[0] - ($NR / 100000) ;                     Interest X
    ;$TarPos[1] = $TarPos[1] + ($NR / 100000) ;                     Interest Y
    $TarPos[2] = $TarPos[2] + $NR ;                                 Interest Z


    Local $E = Euler($CamPos[0], $CamPos[1], $CamPos[2], $TarPos[0], $TarPos[1], $TarPos[2])
    Local $Yaw = $E[0]
    Local $Pit = $E[1]

    $Yaw = $Yaw - 90                                                
    $Pit = $Pit + 90                                                

    ConsoleWrite("Yaw: " & $Yaw & @LF)
    ConsoleWrite("Pit: " & $Pit & @LF & @LF)

    KML($CamPos[0], $CamPos[1], $CamPos[2], $Yaw, $Pit, 0, $TarPos[0], $TarPos[1], $TarPos[2])
    Go(1000)

Next


Func KML($long, $lat, $alt, $head, $tilt, $roll, $longP, $latP, $altP)

    ; Open File
    Local $H = FileOpen($P, 2) ; Open Overwrite
    ; Header
    FileWriteLine($H, '<?xml version="1.0" encoding="UTF-8"?>')
    FileWriteLine($H, '<kml xmlns="http://www.opengis.net/kml/2.2" xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns:kml="http://www.opengis.net/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom">')
    FileWriteLine($H, '<Document>')
    FileWriteLine($H, '<name>IntPos.kml</name>')
    ; Camera
    FileWriteLine($H, '<Camera>')
    FileWriteLine($H, '<longitude>' & $long & '</longitude>')
    FileWriteLine($H, '<latitude>' & $lat & '</latitude>')
    FileWriteLine($H, '<altitude>' & $alt & '</altitude>')
    FileWriteLine($H, '<heading>' & $head & '</heading>')
    FileWriteLine($H, '<tilt>' & $tilt & '</tilt>')
    FileWriteLine($H, '<roll>' & $roll & '</roll>')
    ;FileWriteLine($H, '<altitudeMode>relativeToSeaFloor</altitudeMode>')
    FileWriteLine($H, '<altitudeMode>relativeToGround</altitudeMode>')
    FileWriteLine($H, '</Camera>')
    ; Pin
    FileWriteLine($H, '<Placemark>')
    FileWriteLine($H, '<name>Pin</name>')
    FileWriteLine($H, '<Point>')
    FileWriteLine($H, '<extrude>1</extrude>')
    FileWriteLine($H, '<altitudeMode>relativeToGround</altitudeMode>')
    FileWriteLine($H, '<drawOrder>1</drawOrder>')
    FileWriteLine($H, '<coordinates>' & $longP & ',' & $latP & ',' & $altP & '</coordinates>')
    FileWriteLine($H, '</Point>')
    FileWriteLine($H, '</Placemark>')
    ;End
    FileWriteLine($H, '</Document>')
    FileWriteLine($H, '</kml>')
    ;Close File
    FileClose($H)

EndFunc   ;==>KML

Func Go($Pause)

    ; Execute KML in Google Earth

    If Not WinExists("Google Earth Pro") Then Exit

    ShellExecute($P)
    Sleep($Pause)

EndFunc   ;==>Go

 

 

LookAt.dll

Edited February 4, 2019 by Blaxxun

[RTFC]

7 hours ago, Blaxxun said:

this number: 0.0000000000000000000000000001

thats 28 digits after comma.

You're confusing the size of a number with computational precision. Floats, doubles, and long doubles are represented internally by signed mantissa and signed exponent, like scientific notation for humans. The binary size of the mantissa then determines how many significant digts are stored, but it does not matter a hoot whether these reside very close to zero on the "number line," or close to infinity (the only issue is that the spacing between exactly representable reals slowly grows with absolute distance from zero, a non-issue in your case with values restricted to a few radians). So you don't need long doubles for your computation (your example = 1.0e-28 technically requires  only 1 digit for the mantissa, whereas doubles provide about 12 in base-10 representation). And AFAIK, AutoIt trig functions all use doubles internally anyway, so that should be plenty for your purpose. Thus the answer to your question:

7 hours ago, Blaxxun said:

Can i still calculate with such small numbers without loosing precision?

is yes.

Regarding your statement "the interest and the camera will never be on the same Z-Axis," you seem to be labouring under the mistaken belief  that gimbal lock can only occur at the poles. Its not a question of where in absolute space, its a question of when any two axes are made to align due to some sequence of prior rotations (which is why I suggested 3D rotations always be applied as quaternions; the extra degree of freedom ensures that a. this problem cannot occur, and b. the applied rotation is the shortest arc).

Edited February 4, 2019 by RTFC

[Blaxxun]

@RTFC

Okay, so you say numbers with 28 digits after comma can be calculated without any loss or rounding errors when the numbers after zero are

all zeros and with a one (1) at the very end.

What about real world situations where all these nulls are actual numbers?

How is it then?

 

My opinion about gimbal lock was based on my knowledge of this problem in my 3D Software. When i move a camera with a direction constraint (camera with a null object where the null object is the interest) exactly over or under this null it starts to flip.

 

However.

I will go the route with the quaternions now.

Maybe someone can point me in the right direction on how to start and give me a rough outline of what steps i need so i can

start research.

Like:

1. Given two points in space Camera X,Y,Z and Interest X,Y,Z

2. Calculate direction vector (LookAt)

3. Blablabla

 

Thanks!

Edited February 4, 2019 by Blaxxun

[jchd]

10 hours ago, Blaxxun said:

Okay, so you say numbers with 28 digits after comma can be calculated without any loss or rounding errors when the numbers after zero are

all zeros and with a one (1) at the very end.

Try by yourself and decide which representation is the most readable:

Local $aValues = [ _
    1/3, _
     123e35, _
     123 * 10 ^ 167, _
    -123e167, _
    -123e-167, _
    1e-100, _
    0.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001, _   ;
    0.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000123456789 _
]

For $v In $aValues
    ConsoleWrite($v & StringFormat(" = %170.170f\r", $v))
Next

I'm sorry to inform you we don't live in Care Bears' (Bisounours', Calinours') world.

The "no rounding error" part is impossible with binary floating-point. Almost all real values (I mean points in ℝ) can't be represented exactly without an infinite-precision mantissa. In the examples above you can see that there are often spurious minor errors in least significant digit(s). This is IEEE754 (and binary FP in general) and you can't do anything to fix that, unless you switch to decimal FP (a huge beast).

That said, accumulation of rounding errors in inconspicious-looking computations can sometimes lead to catastrophic situations when one isn't aware of what's actually going on under the hood:

Read the paper mentionned in above code comments and teach yourself basic FP using ressources available on the web.

Edited February 5, 2019 by jchd

[RTFC]

There are existing libraries for that sort of thing that should provide functional templates of what you wish to achieve, for example, check out Eigen's (open source) Geometry module here. Furthermore, a basic conversion from Euler to Quat (in C++) (from here) is:

{
	FQuat q;											// Declare output quaternion
	float yaw = Current_Rotation.Yaw * PI / 180;		// Convert degrees to radians 
	float roll = Current_Rotation.Roll * PI / 180;
	float pitch = Current_Rotation.Pitch * PI / 180;

	double cy = cos(yaw * 0.5);
	double sy = sin(yaw * 0.5);
	double cr = cos(roll * 0.5);
	double sr = sin(roll * 0.5);
	double cp = cos(pitch * 0.5);
	double sp = sin(pitch * 0.5);

	q.W = cy * cr * cp + sy * sr * sp;
	q.X = cy * sr * cp - sy * cr * sp;
	q.Y = cy * cr * sp + sy * sr * cp;
	q.Z = sy * cr * cp - cy * sr * sp;

	return q;											// Return the quaternion of the input Euler rotation
}

That's part of a simple mod for Unreal Engine (engine and mod are free for personal use at the time of writing, AFAIK). My broader point though, is that you're attempting to reinvent the wheel, which is great for training purposes, personal growth, and world peace, but requires significant investment in time and effort on your part to bear fruit. Case in point, your "LookAt function" is a standard call in the core functionality of most modern rendering engines (so studying their source where available would be another possible starting point if you really wish to roll your own). Maybe it's worth considering whether that ready-made integrated power can be wielded and automated more effectively than starting from scratch. In any case, I would suggest you don't get too hung up on FP precision issues; that's a rabbit hole you don't want to go down at this point...

Edited February 6, 2019 by RTFC

[Blaxxun]

@jchd

Thanks for your examples. Iam aware of the rounding error problem.

The question that is interesting for me is: At what point do those errors start?

Are they always happening or just when the digits after comma are getting too many?

@RTFC

I think that you are right. I should not worry too much about the floating point error.

I think it will not have a too big impact on the results (i hope).

Regarding reinventing the wheel.

Well, i want to stay in Autoit and i want to roughly understand whats going on.

At the current state i still dont know what the single steps are.

 

Lets forget about all the floating point and reinventing the wheel topics please.

As soon as i know the single steps i can look into those steps myself.

 

I just need to know the necessary steps:

1. Given 2 points in space Camera XYZ and Interest XYZ

2. Create vector (LookAt)

3. ????

 

Thanks!

[RTFC]

Would you like extra fries with that?

Seriously, I've already provided you with several references, explaining the concept and math implementations in Eigen and Unreal, plus a code example of Euler to Quat conversion. Furthermore, if you're wedded to OpenGL, it too already provides a standard LookAt implementation. Or just google "LookAt vector" to access additional info and code examples. You should be able to figure out the remaining steps, as you're 90% there already. Best of luck.