rotation glitches when reaching 360 degrees: Page 2

rotation glitches when reaching 360 degrees

xyz

I'd do it from controller/mouse deltas, or if you must deal with movement - again from transformation basis/quaternions.

xyz

Here's a way to calculate offsets from difference in rotation between frames. Using quaternions will ensure there are no wrapping and gimbal problems. You'll need to maintain player/camera basis from the previous frame:

calculate_sway_offset(basis_last_frame: Basis, basis_current_frame: Basis):
	var q1 = basis_last_frame.get_rotation_quat()
	var q2 = basis_current_frame.get_rotation_quat()
	var q = q1.inverse() * q2
	var eu = q.get_euler()
	return Vector2(eu.y, eu.x)

cybereality

Right, but this is also why Euler is much easier when starting out. It took me years to fully understand Quaternions, but I guess if you use Godot it does most of the math for you (but you still kind of have to understand what you're doing).

DJM

@xyz said: Here's a way to calculate offsets from difference in rotation between frames. Using quaternions will ensure there are no wrapping and gimbal problems. You'll need to maintain player/camera basis from the previous frame:
calculate_sway_offset(basis_last_frame: Basis, basis_current_frame: Basis):
	var q1 = basis_last_frame.get_rotation_quat()
	var q2 = basis_current_frame.get_rotation_quat()
	var q = q1.inverse() * q2
	var eu = q.get_euler()
	return Vector2(eu.y, eu.x)

ok heres what ive got right now, based on your code

func _process(delta):
	
	var softness = 3.0
    do_sway(weaponsway, calculate_sway_offset(), delta * softness)
	
	
calculate_sway_offset(basis_last_frame: Basis, basis_current_frame: Basis):
	var q1 = basis_last_frame.get_rotation_quat()
	var q2 = basis_current_frame.get_rotation_quat()
	var q = q1.inverse() * q2
	var eu = q.get_euler()
	return Vector2(eu.y, eu.x)
 
    
func do_sway(sway_node, offset: Vector2, fract: float):
	var offset_quaternion: Quat = Quat(Vector3.UP, offset.x) * Quat(Vector3.RIGHT, offset.y)
	sway_node.transform.basis = Basis(Quat(sway_node.transform.basis).slerp(offset_quaternion, fract))

im not sure what to write in the > do_sway(weaponsway, calculate_sway_offset( "what goes here?"), delta * softness) i cant use mouse rotation , because it will sway the weapon even if theres no rotation happening.

xyz

@DJM said: im not sure what to write in the > do_sway(weaponsway, calculate_sway_offset( "what goes here?"), delta * softness) i cant use mouse rotation , because it will sway the weapon even if theres no rotation happening.

What were you trying to base the sway on in the first place? It's typically done based on mouse input. In your initial post you said you want to base it on player and camera rotations. I'm not sure I understand why are you trying to base it on both.

In my example, I assumed you want to do it based on changes in camera rotation - bigger the change, larger the offset. To do this you use camera rotations in previous and current frames (represented by transform basis) as arguments to that function. The function extracts "horizontal" and "vertical" camera rotatation deltas from total rotation of the camera between consecutive frames.

var basis_last_frame = Basis()
func _process(delta):
	var basis_this_frame = $cam.transform.basis
	var offset = calculate_sway_offset(basis_last_frame, basis_this_frame)
	do_sway($sway, offset, delta * softness)
	basis_last_frame = basis_this_frame;

$sway and $cam are paths to your actual sway and camera nodes. In fact $cam stands for the node that does actual rotation in respect to global space. I'm assuming it's the player node in your case.

Of course you can base this offset on other things, depending on your system and actual effect you want to achieve. So it's up to you to decide that. I'd base it simply on InputEventMouseMotion.relative. In which case the whole calculate_sway_offset() function in my previous post can simply return mouse offsets. It just needs to return zero offset if mouse motion didn't happen in the current frame and it'll all work fine.

xyz

@cybereality said: Right, but this is also why Euler is much easier when starting out. It took me years to fully understand Quaternions, but I guess if you use Godot it does most of the math for you (but you still kind of have to understand what you're doing).

One doesn't really need to fully understand quaternions and all the related math to be able to use them for 3d graphics. They have a wide general usage in math but in the world of computer graphics quaternion can be seen simply as a matrix-light that covers only rotations. You can use it as a black box that has certain neat properties and does certain useful things for you. Most people successfully use 4x4 transformation matrices this way.

But yeah, it's true that quaternions may look like an overkill for simple stuff that can kinda be solved using eulers. Especially when you see them for the first time. However eulers grossly fall short if you need to deal with lots of 3d orientation/targeting stuff, as is the case with first person shooters. Quaternions can handle most of such problems with ease in just a few lines of code.

DJM

@xyz said:

@DJM said: im not sure what to write in the > do_sway(weaponsway, calculate_sway_offset( "what goes here?"), delta * softness) i cant use mouse rotation , because it will sway the weapon even if theres no rotation happening.

What were you trying to base the sway on in the first place? It's typically done based on mouse input. In your initial post you said you want to base it on player and camera rotations. I'm not sure I understand why are you trying to base it on both.

In my example, I assumed you want to do it based on changes in camera rotation - bigger the change, larger the offset. To do this you use camera rotations in previous and current frames (represented by transform basis) as arguments to that function. The function extracts "horizontal" and "vertical" camera rotatation deltas from total rotation of the camera between consecutive frames.
var basis_last_frame = Basis()
func _process(delta):
	var basis_this_frame = $cam.transform.basis
	var offset = calculate_sway_offset(basis_last_frame, basis_this_frame)
	do_sway($sway, offset, delta * softness)
	basis_last_frame = basis_this_frame;
$sway and $cam are paths to your actual sway and camera nodes. In fact $cam stands for the node that does actual rotation in respect to global space. I'm assuming it's the player node in your case.

Of course you can base this offset on other things, depending on your system and actual effect you want to achieve. So it's up to you to decide that. I'd base it simply on InputEventMouseMotion.relative. In which case the whole calculate_sway_offset() function in my previous post can simply return mouse offsets. It just needs to return zero offset if mouse motion didn't happen in the current frame and it'll all work fine.

tnx for your reply it sort of works but sway happens only on one axis, if i set $cam to the player node it rotates horizontaly if i set $cam to the camera node it happens only vertically

idont ant to use mouse motion as when u are looking down and the rotation is clamped , u will still get weapon sway even if there is no actual rotation happening

xyz

Well that's probably because different nodes handle rotations on different axes in your setup. You can simply do the basis thing for both nodes, calculate both offsets and then use horizontal offset from one, and vertical offset from the other.

var cam_basis_last_frame = Basis()
var player_basis_last_frame = Basis()

func _process(delta):
	var cam_basis_this_frame = $cam.transform.basis	
	var player_basis_this_frame = $player.transform.basis
	var offset1 = calculate_sway_offset(cam_basis_last_frame, cam_basis_this_frame)
	var offset2 = calculate_sway_offset(player_basis_last_frame, player_basis_this_frame)
	var offset = Vector2(offset1.x, offset2.y) #may need to swap 1 and 2
	do_sway($sway, offset, delta * softness)
	cam_basis_last_frame = cam_basis_this_frame;
	player_basis_last_frame = player_basis_this_frame;

xyz

I'm beginning to think that wrapped-euler approach may be simpler for calculating the offsets here :)

DJM

@xyz said: I'm beginning to think that wrapped-euler approach may be simpler for calculating the offsets here :)

so my initial idea was better?

xyz

@DJM said:

@xyz said: I'm beginning to think that wrapped-euler approach may be simpler for calculating the offsets here :)

so my initial idea was better?

It's the same thing. Quaternions will elegantly eliminate all wrapping and gimbal lock glitches, which was the problem in the first place. Since angles are already separated into different nodes, @cybereality's euler wrap solution will do that job as well. However, even if offset is obtained directly from euler angles I'd still use quaternion slerping for setting the sway node rotation.

If you're working on a first person shooter thingy, don't shy sway from quaternions, but rather get acquainted with them. You'll need their help again... sooner or later :)

DJM

@xyz said: Well that's probably because different nodes handle rotations on different axes in your setup. You can simply do the basis thing for both nodes, calculate both offsets and then use horizontal offset from one, and vertical offset from the other.
var cam_basis_last_frame = Basis()
var player_basis_last_frame = Basis()

func _process(delta):
	var cam_basis_this_frame = $cam.transform.basis	
	var player_basis_this_frame = $player.transform.basis
	var offset1 = calculate_sway_offset(cam_basis_last_frame, cam_basis_this_frame)
	var offset2 = calculate_sway_offset(player_basis_last_frame, player_basis_this_frame)
	var offset = Vector2(offset1.x, offset2.y) #may need to swap 1 and 2
	do_sway($sway, offset, delta * softness)
	cam_basis_last_frame = cam_basis_this_frame;
	player_basis_last_frame = player_basis_this_frame;

tried it, now the gunsway rotates out of camera view and just gets all the rotation from the player and cam applied

xyz

Let's see the actual code.

DJM

@xyz said: Let's see the actual code.

`func _process(delta): window_activity() var softness = 3.0 var cam_basis_last_frame = Basis() var player_basis_last_frame = Basis()

var cam_basis_this_frame = $CamRoot.transform.basis 
var player_basis_this_frame = self.transform.basis
var offset1 = calculate_sway_offset(cam_basis_last_frame, cam_basis_this_frame)
var offset2 = calculate_sway_offset(player_basis_last_frame, player_basis_this_frame)
var offset = Vector2(offset2.x, offset1.y) #may need to swap 1 and 2
do_sway(weaponsway, offset, delta * softness)
cam_basis_last_frame = cam_basis_this_frame;
player_basis_last_frame = player_basis_this_frame;

func calculate_sway_offset(basis_last_frame: Basis, basis_current_frame: Basis): var q1 = basis_last_frame.get_rotation_quat() var q2 = basis_current_frame.get_rotation_quat() var q = q1.inverse() * q2 var eu = q.get_euler() return Vector2(eu.y, eu.x)

func do_sway(sway_node, offset: Vector2, fract: float):
	var offset_quaternion: Quat = Quat(Vector3.UP, offset.x) * Quat(Vector3.RIGHT, offset.y)
	sway_node.transform.basis = Basis(Quat(sway_node.transform.basis).slerp(offset_quaternion, fract))
`

xyz

cam_basis_last_frame and player_basis_last_frame need to be sctipt-level properties, not local variables. They are used to "remember" basis values from the last frame. If you declare them as local variables inside _process(), like you're doing now, they'll just be deleted when function exits, serving no purpose.

p.s. please fix the code formatting.

DJM

@xyz said: cam_basis_last_frame and player_basis_last_frame need to be sctipt-level properties, not local variables. They are used to "remember" basis values from the last frame. If you declare them as local variables inside _process(), like you're doing now, they'll just be deleted when function exits, serving no purpose.

p.s. please fix the code formatting.

tnx! that fixed it, now im using quaternions to do the sway. just curious, are quaternions more efeccient than euler angles?

and yeah i dont really know how to insert code properly. ive pasted the code between the code brackets but it doesnt appear correct

cybereality

For code on the forum, type 3 tildes on a line by itself directly above and below the code "~~~"

xyz

@DJM said: tnx! that fixed it, now im using quaternions to do the sway. just curious, are quaternions more efeccient than euler angles?

Depends on what you mean by 'efficient'. Quaternions are conceptually and mathematically better suited for dealing with spatial rotations. And in the end they result in less code and less confusion than eulers for more complex problems.

The strength of quaternions is that they can easily represent rotation around any spatial axis, while with eulers you are limited to 3 orthogonal axes that you need to combine in a specified order to bring the object to particular orientation in space. On top of that, quaternion rotations can be accumulated by simply multiplying the quaternions (similar to transformation matrices) as well as interpolated by the shortest possible path between two arbitrary 3d orientations. It's very elegant and clean compared to what you need to do with eulers to achieve same results.

Some rotational animations are practically impossible without quaternions. For example a turret with 3 degrees of freedom changing the aim, rotating by the shortest path. Interpolating this with eulers will result in all sorts of unwanted behaviors. Quaternions handle it perfectly.

cybereality

Matrices will solve many of the same problems, however require 9 floats for rotation (or 16 floats for rotation and position) while Quaternions only require 4 floats. So they are more optimized in terms of space than a Matrix, and are also somewhat easier to work with (like for interpolation). Euler will require the rotation amount (1 float) and the axis (3 floats) so the space is the same, but once you get into more advanced features (on top of all the code to handle Euler deficiencies) then Quaternions will be better overall.

DJM

interesting

« Previous Page Next Page »