Convert HPR to normalized Vector

Hi!

I had to mess around with normals again and after not getting
the typical “use a dummy node” technique to work, I wanted a simple alternative.

I’ve googled for it, but this seems to be the simplest
and most straight forward solution to get the LookAt vector of the base camera.

And it’s really easy! :slight_smile:

LookAt = base.camera.getHpr()/180
LookAt.normalize()

Boom!

HPR range from -179 to +179, “left” and “up” go into the positives,
meaning that a Heading of +1 equals rotating your head to the left.

I hope whoever finds this finds it as usefull as I do!

That’s a neat little trick! I haven’t checked it thoroughly, but it does seem as though it should work. :slight_smile:

That said, is the “lookAt” vector of the camera not just its “forward” vector, as returned by “base.camera.getQuat().getForward()”?

Ha, didn’t know that one. Whenever I googled for the LookAt/Forward,
everyone get’s told to make a dummy node and use getRelativeVector.

I’ll give this a try. :slight_smile:

You don’t get a vector from dividing three euler angles by 180 (it’s a lot less trivial than that). Nor do you need a dummy node. This is the most common way to do it:

render.getRelativeVector(base.camera, (0, 1, 0))

@rdb: I’m curious: what is the difference between the output of

render.getRelativeVector(base.camera, (0, 1, 0))

and

base.camera.getQuat().getForward()

if the camera is attached to render, or

base.camera.getQuat(render).getForward()

otherwise?

It’s weird, because it worked. I compared my numbers to the RelativeVector and they’re way off.

Sheesh … and I made this thread. I’m not even using this anymore, it was only briefly.

Argh. -.-

@Thaumaturge: there probably is none - except that your method will only work to get a vector relative to the parent node, of course.

Surely providing a NodePath parameter to “getQuat” allows one to get the rotation, and thus the forward vector, relative to the specified NodePath?

Unless you mean that “getQuat” only allows one to get a rotation relative to one of the relevant node’s ancestors (not just its immediate parent node), while “getRelativeVector” works for any pair of NodePaths…?

Of course; both will work with any two nodepaths that are in the same scene graph. Both are just different ways to get the same result - one using quaternions, and the other via transformation matrices.

getRelativeVector is defined as the equivalent of this:

def getRelativeVector(self, other, vector):
    return vector * other.getMat(self)

In that sense, I suppose the main advantage of getRelativeVector is that you can pass any vector to it, not just the forward vector.

Since getRelativeVector uses only matrix multiplication, it does seems to be marginally faster, but passing Vec3.forward() to it instead of (0, 1, 0) to make it work when Panda is configured to a different coordinate system makes it slightly slower due to the extra function call to C++.

Ah, that’s interesting, and thank you. :slight_smile:

One way or another, “getRelativeVector” looks like a method to bear in mind!

I like how this thread didn’t turn completely useless.

Thanks! :slight_smile: