3D Rotations in 2D Games

Lake

Read title. This is something I'd like to do.

Here I have frames of animation for a head. The head has 26 frames of animation for looking up, down, left, right, forward, and backward, and the 45 degree angles in-between - equivalent to the normals of a Rhombicuboctahedron. Each frame can be rotated in 45 degree increments to get 8 positions each. I thus have 208 animation states.

I want to implement this in code by storing an orientation state, and a rotational velocity. I worry that Euler angles would give me the same problems as in 3D. I've thought of using Quaternions, but I don't know how I'd extract my animation state from them. I'd eventually like to build sprite-node bodies that could move and rotate in orthographic space, but one thing at a time, I suppose.

I am more an artist than a programmer. If someone has insights into this problem, it would be much appreciated.

Wolfe

I'm not much of a programmer either, but I think I can point you in the right direction. I suggest using an invisible Spatial node as a child of the 2D object to track its 3D orientation. This way you can use Godot's built-in 3D functions. B)

I figure Euler angles are the output you want for the 2D object. I tried relying on the transformation matrix or a quaternion instead, but kept ending up with Euler angles again when it came time to codify the rotations into something that made sense for calling the sprites/animations.

I've worked with 8-way sprites before, so I've got a nifty equation that provides the desired 45-degree window for a given Euler angle.

extends Spatial

var facing: Vector3

func _ready():
	# Deliberately add error to encourage consistent behavior from the start
	rotate_y(PI)
	rotate_y(-3.1415926)

func _process(delta):
	## ...perform rotations as desired... ##
	# Get facing and convert to number from 0-7 for every 45 degrees (PI / 4)
	facing = transform.basis.get_euler()
	facing.x = rad2eight(facing.x)
	facing.y = rad2eight(facing.y)
	facing.z = rad2eight(facing.z)

func rad2eight(theta):
	return fposmod(round(theta * 4 / PI), 8)

Judging from the output console, "facing" exhibits the upside-down flips Euler angles are known for, but I think it could still work:

Once any significant yaw or roll has taken place, facing.x appears to be confined from down to up (6, 7, 0, 1, 2). Keeping that consistent is the purpose of the contents of _ready. Once facing.x is confined, it looks like facing.y and facing.z flip instantly, given such a small resolution for the rotations and the "window" my function provides.

In other words, when the flip occurs (at 90 degrees up or down), the sprite should instantly roll 180 degrees and yaw 180 degrees. I tried to make this consistent to lighten your workload, because it should cut down the number of sprites/animations to assign. Any orientation where the top of the object is pointing below the horizon (basis.y.y is negative) necessitates roll thanks to the Euler flip, so a duplicate like (4, 0, 0) becomes (0, 4, 4).

Maybe the scourge of Euler angles is actually helpful here? :p

Lake

Thank you wolfe. It is an interesting approach, but I count 320 animation states rather than the 208 my representation actually should. I worry to, given the physics I'd like to do, that Euler angle's could be a liability.

The approach I'm currently thinking of is to store my rotation values in a quaternion. I figure that if I take the Y vector (0,1,0), representing a head facing forward, and call xform on it, the vector I get back will tell me which way the head ought to be pointing. Let's call this the facing vector.

Then, if I call xform on the Z vector (0,0,1), representing the top of the head pointing up, I should know how much the face will be rotated around the facing vector as its axis, say, by using the cross-product of the facing vector and the X vector (1,0,0) as a reference.

Then, I just look for which of the 26 directions and 8 rotations I'm closest too.

Now, if I could find the quaternions that represent these 208 states and look for the closest of those, that'd be even better, assuming any of this works like I expect.

Wolfe

@Lake said: Thank you wolfe. It is an interesting approach, but I count 320 animation states rather than the 208 my representation actually should. There are some duplicates left, yes. To cut it all the way down to 208 I suppose you could zero out "facing.z" and change "facing.y" to account for the extra rotation whenever "facing.x" equals 2 or 6.

Head on its side: (0, 0, 2) Rotating (global) up: (1, 0, 2) Facing (close to) up: (2, 2, 0) instead of (2, 0, 2) Facing (just past) up: (2, 2, 0) again instead of (2, 4, 6) Continuing on: (1, 4, 6)

(2, 0, 2) and (2, 4, 6) would be two of the 112 duplicates. In other words, the "200s" would be (2, 0, 0) through (2, 7, 0) incrementing on Y, and same with (6, 0, 0) to (6, 7, 0). That all seems to add up.

Naturally, I understand preferring to manage 208 sprites/animations instead of 320. :)

What I thought was kind of neat was how the Euler flip this method produces ended up negating the need for a manual check against the last 192 (!) duplicates. (8 8 8 = 512)

I worry to, given the physics I'd like to do, that Euler angle's could be a liability. As I imagine it, the Euler angles are only for output to the 2D sprite, a representation of the results of proper vector/quaternion math, either your own or from a genuine RigidBody, unseen by the player.

It's just one angle-based operation converting each float into a useful integer from 0-7. I envisioned something like:

# suppose facing == Vector3(1, 2, 3)
animation = 'head_' + (facing.x * 100 + facing.y * 10 + facing.z)
# animation changed to 'head_123'