Console spam when camera is gimbal locked with its LookAt target.

[apolesskiy]

Issue description

Behavior:

When the camera is gimbal locked, (e.g. directly above or below its LookAt target), the editor console is spammed with

WARNING: core/math/basis.cpp:1058 - Target and up vectors are colinear. This is not advised as it may cause unwanted rotation around local Z axis.

When the camera is in the same spot as the LookAt target, the console is spammed with

ERROR: The target vector can't be zero.

Desired behavior:
No logspam when camera is gimbal locked, especially in the editor.

Also, it would be great to be able to control camera facing when it is looking straight down at a LookAt target. Right now, it's locked to viewport up = global -x.

Steps to reproduce

1. Set up a PhantomCamera at (0, 10, 0).
2. Create Node3D at (0,0,0)
3. Set PhantomCamera to look at Node3D.
4. Observe warning logspam.
5. Move PhantomCamera to (0, 0, 0).
6. Observe error logspam.

MRP: https://github.com/apolesskiy/phantom-camera/tree/lookat_gimbal_lock_edge_case in dev_scenes/dev_gimbal_lock_edge_case.tscn.

(Optional) Minimal reproduction project

No response

[ramokz]

When the camera is gimbal locked, (e.g. directly above or below its LookAt target), the editor console is spammed with

This is an expected behavior and is an internal Godot message.

The addon uses the built-in Basis().looking_at function to calculate the direction, which is where the errors come from. Think the only two ways around them are to either manually reimplement the same method, and exclude any of the error messages, or apply a tiny offset if the camera is looking directly up or down at its target. Neither are really ideal imo.

Also, it would be great to be able to control camera facing when it is looking straight down at a LookAt target. Right now, it's locked to viewport up = global -x.

There is a recent discussion post about the same topic.
Feel free to join in and share your thoughts on an ideal approach.

[apolesskiy]

Logspam in the editor is not great UX (esp. for automated tooling), and Godot docs do say that Vector3.ZERO and collinear vectors are not valid inputs to Basis.looking_at. It's trivial to check both zero and collinear before calling the method (apolesskiy@9aaf962). That being said, there's a performance argument for not doing a check every frame for a rare and non-fatal condition. Leaving it up to you. I can make a PR if you're interested; otherwise, go ahead and close this.

[ramokz]

I agree that getting a spam warning log isn't a good developer experience under any circumstances. However, considering the messages are warnings and don't actually cause any functional issues, I am not too keen on adding additional calculations and checks just to silence them. To echo your sentiment, it isn't overly common to experience those warnings, yet the added calculations will impact everyone who uses the feature.

Would probably be more inclined to suggest an upstream proposal to add another optional parameter to the Basis.looking_at function where you can supply a boolean to disable any warning output from it; with it being enabled by default. That should allow the user the flexibility to silence warnings that, while present for sensible reasons, can become an issue in some cases (like here). Ultimately, the issue is about just silencing the warning output.