I tried to make a node tree with which the player object “looks to” the mouse location on the screen.
For example, if the mouse is in the upper right corner of the game window, the should be rotated to this corner. So if he would have an always move forward node, he will always go to the location, where the mouse is pointing at.
My current node-tree:
I’ve tried to make it by placing an empty at the mouse location and then rotating the player with a look at and set rotation node. In an older post, I’ve seen, that te look at outputs a quaternion, so I changed the input of the Set Rotation Node to “Quaternion”.
If I compile the game the player starts to rotate weird and slowly glides away.
Does someone sees the mistake, I’ve made?
Thanks for helping.
See "looking At" node with a camera!. “Easiest” solution is not to use euler angles and use quaternions directly, but you may have to code the functionality yourself to make the nodes use quaternions instead. The reason why is detailed in a post from that thread I linked, but basically quaternion to euler conversion has issues that are hard to workaround (in any engine), so you are better off using just quaternions.
Maybe it could output both, or be reverted back to quaternions.
Though the problem with having both is that the pitfall of “wrong rotation” or “wrong looking at” will still be there and so will the posts about them.
That’s why my proposal in this issue is to move past euler angles for rotations.
When talking about rotation, I think the simplest is to calculate and rotate the Transform directly.
- logic node(https://github.com/armory3d/armory/pull/1505)
It is irrelevant for “Look At” because it does not extract rotation from transform.
I agree to unify the rotation input / output of the logic node to “Quartanion”. I think “NodeSocketVector” is used for the input / output of the quaternion, but when this is used on the input side, it looks like Vec3.