headsUp()/rotating nodepath to match up vector snapping relative heading

Scripting Issues
1

Right now I’m trying to work on a class that effectively works as a “gravity field” that calculates an up vector, and then rotates a player character or other game object to have that up vector.
Unfortunately, I’m running into a problem where calling nodepath.heads_up() is constantly causing any nodepath’s relative heading to one or two directions per point in the gravity field. Effectively, it snaps the camera back to a specific direction if you try to look to the left or right.

def _dynamic_set_rotation(self, creature, task):
    upVec = self._get_grav_up_vector(creature)
    if creature.gravUpVec == upVec or creature.velocity.length() == 0: return task.cont

    fwd = creature.np.get_parent().get_relative_point(creature.np, Point3(0,1,0))
    creature.np.heads_up( fwd, upVec )
    creature.gravUpVec = upVec

    return task.cont

For the record, I’ve also tried getting fwd with creature.np.get_quat(creature.np.get_parent()).get_forward() But that caused the same issue with an additional issue of the camera repeatedly turning 180 degrees as the player object moved.
Is there some other way of rotating a game object to match an up vector or some way of using heads_up that’s more forgiving of relative heading?

P.S.:
If it helps, here’s how I’m calculating the up vector for a sphere:

def _get_grav_up_vector(self, player):
    return player.np.get_parent().get_relative_vector(self.np, Vec3(player.np.get_pos(self.np).normalized()))
2

You need a different approach, namely two calculus systems. You are now apparently using the principle of inheritance, in this case the transformation of the camera is imposed by the character. Which apparently doesn’t work as well as we would like, I suggest you synchronize the camera yourself in relation to the character’s body. To do this, you can use world coordinates, for example, you can easily match the position of the head point and the camera. It remains to calculate the direction and acceptable angles of rotation of the camera, relative to the position of the character’s body.

3

Hmm… Maybe, instead of using “heads_up”, it would work better to calculate a rotation to apply to your object.

In short, the smallest rotate between your old orientation and your new orientation should be the angle between the old up-vector and the new up-vector, while the axis around which rotate should be the cross-product of those same two vectors.

With this, you should be able to construct a rotation quaternion, which you could then apply to your object, I believe.

1 Like
4

I like this idea! However, I don’t yet have any experience working with quaternions however. So far, my rotations seem arbitrary, and more prone to affecting gameobjects’ relative heading… Sorry, is there a mistake I’m making here?

def _dynamic_set_rotation(self, creature, task):
    upVec = self._get_grav_up_vector(creature)
    if creature.gravUpVec.almost_equal(upVec) or creature.velocity.length() == 0: return task.cont

    gravAxis = upVec.cross(creature.gravUpVec).normalized()#<-I've tried swapping upVec and gravUpVec
    angle = upVec.angle_deg(creature.gravUpVec)
    newQuat = Quat()
    newQuat.set_from_axis_angle(angle, gravAxis)
    creature.np.set_quat(newQuat * creature.np.get_quat())
    #assert creature.np.get_quat(creature.np.get_parent()).get_up().almost_equal(upVec, 0.00001)
    #^Failing
    creature.gravUpVec = creature.np.get_quat(creature.np.get_parent()).get_up()

    return task.cont

Edit: Experimented on my own to try and get things right, now the player just rotates wildly out of control. I’ve been updating the code I posted above to match what I’ve been trying.

5

I’m not sure of why it’s not working!

A few thoughts:

Should the new value of “gravUpVec” not be just “upVec”?

And there’s always the old standby of trying to negate values (e.g. the angle that you calculate).

Otherwise, if you can put together a short-and-simple test-program, I can try to debug it on my end!

[edit]
One more thought: Have you tested the code that generates up-vectors for your spheres?

It feels… complex, for what it seems to be doing, and without knowing the various details of it (e.g. what “player.np” is parented to) I find it hard to assess what it’s doing…

1 Like
6

That was how I was doing it before, but I realized that if I don’t retrieve the actual up vector for the player’s np, small discrepancies can build up until I’m applying a rotation based on a starting vector totally different from the actual up-vector.

Well, it’s intention is to first get the position of the player (Which is the same kind of object as “creature”, my bad for not keeping the standard) in the space of the spherical gravity field. (This of course assumes that the origin of the spherical gravity field is in the center-of-mass.) Then, it normalizes that vector, and uses get_relative_vector() to translate it into the coordinate-space of player/creature’s parent, as that is also the easiest coordinate space to get the current up-vector in.
In practice, player/creature’s parent is almost always going to be equivalent to base.render, but my game does have ridable entities that creature classes can reparent to/from, so I keep the retrieval dynamic.
(As I’m writing this, I realize I should probably just get gravUpVec dynamically; as reparenting can invalidate it)

If I have time later, I might try to split this logic from my larger project for debugging. However, I have other things that take priority today.

In the mean time, thanks for your help!

7

This may or may not make sense to you, but when approaching a problem like this, I’d probably get rid of the inheritance-based vector relationships for a start. Then, I’d define a dedicated node for comparison that uses look_at() to get a referential basis for comparisons to arbitrary nodes in the scene graph.

8

Note: Important edit at the end!

Aah, that’s a fair point. Okay!

For the case of ridable creatures, I’d suggest applying this logic to the creature, and then simply parenting the player to that creature, allowing the player’s orientation to then naturally follow that of the creature.

Quite how this would be handled internally might depend on the internal structures of your game.

It might be as simple as replacing the player’s model with that of the creature, attaching the player’s actual model to said creature-model, and then tweaking the player’s values to represent the creature.

Or it might involve temporarily replacing the logical player-object with a new one featuring the creature–keeping the player-object aside for reuse when the player dismounts/loses their ride–and again just reparenting the player-model to the model of that new “player”.

Or something else besides!

Which might lead to a simpler approach to the gravity-vector thing…

Would it not be simpler to just take the player’s new position (relative to “render”), subtract the sphere’s position (likewise relative), and then normalise the result?

That should lead to a vector in world-space that points from the centre of the sphere out to the player’s position on the surface of the sphere, which should match the surface normal at that point, I believe.

[edit]

Update: I found the problem rather interesting, so I decided to sit down and take a shot at it myself.

And I think that I’ve put together a working example program!

It’s rough and simple, but hopefully should demonstrate the principles of the thing.

([edit 2] In this example , the player-driven rotation is overridden by the sphere-surface rotation. Fixing that is left as an exercise for the reader. :stuck_out_tongue: [/edit 2])

Of note:

  • I ended up negating the angle gained from “angleDeg”
  • I’m calculating the up-vector simply from the positions of the player and the sphere
  • The new quaternion is made by multiplying the player’s quaternion by the rotation quaternion–not the other way around!

The program uses Panda’s default models, so it should run just as-is, I believe! :slight_smile:

from direct.showbase.ShowBase import ShowBase

from panda3d.core import Vec3, Quat


class Game(ShowBase):
	def __init__(self):
		ShowBase.__init__(self)
		
		self.disableMouse()

		taskMgr.add(self.update, "update")
		
		self.environment1 = loader.loadModel("environment")
		self.environment2 = loader.loadModel("environment")
		self.environment1.reparentTo(render)
		self.environment2.reparentTo(render)
		self.environment1.setScale(10)
		self.environment2.setScale(10)
		self.environment2.setP(180)
		self.environment1.setZ(-20)
		self.environment2.setZ(20)
		
		self.sphereSize = 10
		
		self.sphere = loader.loadModel("smiley")
		self.sphere.setScale(self.sphereSize)
		self.sphere.reparentTo(render)
		
		self.player = loader.loadModel("panda")
		self.player.reparentTo(render)
		self.player.getChild(0).setScale(0.1)
		self.player.setPos(0, 0, 10)
		
		self.playerLastUpVec = Vec3(0, 0, 1)
		
		self.camera.reparentTo(self.player)
		self.camera.setPos(0, -15, 15)
		self.camera.setP(-45)
		
		self.accept("w", self.setKey, extraArgs = ["forward", True])
		self.accept("s", self.setKey, extraArgs = ["backward", True])
		self.accept("a", self.setKey, extraArgs = ["left", True])
		self.accept("d", self.setKey, extraArgs = ["right", True])
		
		self.accept("w-up", self.setKey, extraArgs = ["forward", False])
		self.accept("s-up", self.setKey, extraArgs = ["backward", False])
		self.accept("a-up", self.setKey, extraArgs = ["left", False])
		self.accept("d-up", self.setKey, extraArgs = ["right", False])
		
		self.keys = {
			"forward": False,
			"backward": False,
			"left": False,
			"right": False,
		}
		
	def setKey(self, key, state):
		self.keys[key] = state

	def update(self, task):
		dt = self.clock.getDt()
		
		spherePos = self.sphere.getPos(render)
		
		playerTurnSpeed = 50
		playerSpeed = 10
		playerQuat = self.player.getQuat(render)
		playerForward = playerQuat.getForward()
		
		if self.keys["forward"]:
			self.player.setPos(self.player.getPos() + playerForward * playerSpeed * dt)
		if self.keys["backward"]:
			self.player.setPos(self.player.getPos() - playerForward * playerSpeed * dt)
		if self.keys["left"]:
			self.player.setH(self.player, playerTurnSpeed * dt)
		if self.keys["right"]:
			self.player.setH(self.player, -playerTurnSpeed * dt)
			
		playerMovedPos = self.player.getPos(render)
		
		upVec = playerMovedPos - spherePos
		upVec.normalize()
		
		self.player.setPos(render, spherePos + upVec * self.sphereSize)
		
		angle = upVec.angleDeg(self.playerLastUpVec)
		axis = upVec.cross(self.playerLastUpVec)
		
		if axis.length() > 0.00001:
			axis.normalize()
			
			rotation = Quat()
			rotation.setFromAxisAngle(-angle, axis)
			
			newQuat = playerQuat * rotation
			self.player.setQuat(newQuat)
			
			self.playerLastUpVec.set(upVec.x, upVec.y, upVec.z)
		
		return task.cont


app = Game()
app.run()
2 Likes
9

Thanks to you checking for that specific case in your example program, I was able to discern that the problem with arbitrary rotations was due to the cross product between the new and old vectors being too small. Thank you so much for your help!

1 Like