 # "looking At" node with a camera!

hello,

I found the “looking At” node and I use it with a camera!

But, I have to apply the trait on an empty as parent of cam. And fix the camera rotation with (90,0,-90).

It’s very wierd we can’t use “looking At” directly with a camera!?
Why do you use it?

You can apply it to the camera, but the problem is that the LookAt node works strange by itself.
LookAt.blend (107.4 KB)

TL;DR: The “strangeness” comes from the conversion between euler angles and quaternions. In the node you see (x,y,z) to represent the rotation but internally is using (a,b,c,d) to perform the calculations because is more convenient and is not affected by issues like gimbal lock. But this has a problem, the conversion back from (a,b,c,d) to (x,y,z) has multiple results (or representations), and is complicated to guess what was the result the user expected.

When you want to rotate something there is a conversion from the input of the user (x,y,z)(Euler angles) to (a,b,c,d)(Quaternion). After converting to (a,b,c,d) the calculations are done to perform the rotation and then the result is converted back to (x,y,z) for the user to see.

The problem comes when converting back from (a,b,c,d) to (x,y,z): There are multiple representation for (a,b,c,d) in (x,y,z), that is the result you expected and the result you got.

You can obtain both internally but the problem is guessing what was the result the user expected.

Some stuff can be done to aid this issue but they are not perfect and still break, you can test this yourself in more mature engines that rotation using (x,y,z) in multiple angles can break too!

So it’s a presentation vs usability problem. The rotation nodes and the Transform could be modified to instead of using (x,y,z) uses (a,b,c,d) directly and the problem would be gone, but you will loose the “convenience” of (x,y,z).
Some engines prefer simply to encourage using quaternion instead of (x,y,z) to solve the issue.

A solution would be, modifying the lookAt node to return a value of (a,b,c,d), skipping the conversion, and then the Transform node could be changed to receive (a,b,c,d) instead of (x,y,z) and that would solve the issue I think. The problem is if the user has no issue not seeing (x,y,z) anywhere.

I will try later to post here some modified version of the nodes to test it.

Hello,
I am no programer but I’ve been working on my own “Track to” Node for a while ( which is kinda similar ).

This forum helped me to figure how to proceed but the problem I found is that the " fromEuler " function converts Quaternion from YZX Euler ( which Gimbal Lock on the Y axis) , instead of XYZ Euler ( which Gimbal Lock on the Z axis).

As a test I wanted to create my own node with the XYZ Euler to Quaternion conversion.
I based my node on the “Track to” Actuator from BGE which I’m use to. Edit:
I upload the Node to whoever want to try it.

The Node definition ( it’s a python file, just remove the “.hx” extention to make it work ):
track_to_test.py.hx (1.4 KB)

The Node Itself:
TrackToTestNode.hx (6.6 KB)

There, I hope it could help somebody.
Again I’m no programmer so the code might be messy.

1 Like