My subject pretty much asks the question.
Has anyone built a lookAt function that doesn’t have the gimbal-lock flipping problem when you pass one of the poles of the object being looked at and are you willing to share ? 
Thanks for any help.
Kind regards,
Mr P
yeah,
NodePath.lookAt has no gimbal-lock problems. You must be running into some thing else.
The gimbal-lock problem of NodePath.lookAt() is not related to the use of Euler angles. NodePath.lookAt() doesn’t use Euler angles internally; it is matrix-based, which is even better than quaternion-based.
There is a gimbal-lock problem with NodePath.lookAt(), though, and it’s the same problem that you would have with any implementation of lookAt(). To understand the problem completely, you have to understand what lookAt() is doing.
There are two vectors involved in lookAt(): the “look at” vector, and the “up” vector. One vector alone is not sufficient, because it is ambiguous. Think of it this way: once your model is oriented to be looking down the “look at” vector, which way is up? Which way should your model be rotated about the look at vector itself?
To resolve this, you need a second vector, the “up” vector. lookAt() is defined to move the Y axis of the model in alignment with the “look at” vector, and then to rotate the Z axis of the model so that it is in the same plane as the “up” vector.
This resolves the ambiguity. But what happens when you use the same vector for both the “look at” vector and the “up” vector? Suddenly, the ambiguity returns. The model doesn’t know which way to position itself on the axis. It might flip about the axis at random.
This is the gimbal lock problem. It happens whenever you ask lookAt() to look straight down (or nearly straight down) the Z axis, since the Z axis is the default up vector. There are two solutions:
(1) Avoid looking down the Z axis.
(2) If you must look down the Z axis, specify a different up vector.
David
Thanks again David,
That makes perfect sence now.