Does the implementation of the look_at() function affect Godot's performance?

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By Kreaninw

In order to actually make the object look at the target, the user will need to invert the object’s rotation with code: rotation_object_local() or purposely turn back the object in the scene beforehand which is counter-intuitive by the way. And not to mention that this function does exactly the opposite of what its name implied.

This intended quirk aside, will it affect the performance if I decide to do it with code?

If your object is facing the wrong way, this hints that its initial rotation isn’t correct. Remember that in Godot, the “forward” direction is Z- (see Vector3.FORWARD).

Calinou | 2021-02-04 21:05

I totally get it now. And I just noticed that, actually, when I moved the x and y axis in the direction where the gizmos’ arrow is pointing, the translation value will be positive. Only the z axis’ translation will respond to the gizmos’ pointing direction in a negative value, which is not consistent with other axes at all.

And with the understanding that when I open a 3D scene in Godot, I was always working behind the model, not in its front, I think I clearly see how things work in Godot now.

However, I personally think that the current implementation is very confusing. The main issue is that the gizmos’ arrow is pointing backward only for the z axis. It’s not just counterintuitive and inconsistent with other axes but it’s also contrary to everything we learned in life, for instance, I would normally move forward to a direction where the arrow is pointing at. But in Godot, it’s the opposite (and only for the z axis too).

Kreaninw | 2021-02-04 23:40

:bust_in_silhouette: Reply From: Wakatta

func observe(target):
	look_at(Vector3(target), Vector3.UP)
	rotate_object_local(Vector3.UP, PI)

Godot is open source so if you don’t like a “quirk” as you’ve called it, you can recompile it to suit your tastes or extend with an Editor Plugin.

All physics related functions seem to cause noticeable performance hiccups when called too often. And by often i mean like 100 nodes every single frame. So a good practice may be to use them under specific if-else conditions. Other than that it will not affect performance in the slightest to use the above code.

I believe that anyone who asks this question will unlikely to have the capability to modify the engine source themself. Otherwise, they would have done so without asking

Anyway, this answered my curiosity. I shouldn’t worry too much about the performance if that is not a hundred of them together every single frame.

Thanks for the answer, I will mark this as an answer.

Kreaninw | 2021-02-04 14:26