#I'm for help with quarternion rotations
echo stirrup
https://store.steampowered.com/app/1459280/Attaboy/
its the second video here (from alpha)
but that implementation is sloppy
tulip marten
can you maybe explain it succinctly in words?
echo stirrup
Alright! Imagine a 2D game. There is an airplane. The airplane can move on the Z (sideways on the screen)-axis and Y-axis (up and down). The plane can angle, meaning the nose can point up or down at the ground. Now the problem arrives as you keep pitching up the nose, at one point you will be flying inverted (upside-down). The remidy this, the plane needs to be able to flip over. I want to do this by doing a "roll" on the z-axis (forward). However, while i add this "roll" for example something like from the top of my head:
Quaternion quaternion = Quaternion.AngleAxis(10f, Vector3.forward);
transform.rotation = quaternion * transform.rotation;
This will rotate the plane fine, while it is euler (0,0,0) rotation, however, if you change the rotation to a more complex rotation, starting at (45,0,10) it will start to go into values like (45,-2,10).
Please let me know if I still need to make things more clear.
echo stirrup
Could it be related to the rigidbodies tensor settings?
tulip marten
i believe this will make a small rotation about transform.forward. i think what you wrote is slightly flawed in that it is mixing up local and world rotations. imo, you should probably model this physically.
transform.localRotation *= Quaternion.AngleAxis(rotationSpeed * Time.deltaTime, Vector3.forward);
This indeed correctly rotates the objects (had to change transform.forward to Vector3.forward). It continues to work if an object moves without changing other axis (second gif)
transform.localRotation *= Quaternion.AngleAxis(rotationSpeed * 4f * Time.deltaTime, Vector3.forward);
but now simply adding the following code demonstrates the issue
// pitch the plane based on input
rigidbody.AddTorque(transform.right * flipTarget * rotationSpeed * Input.GetAxis("Horizontal"));
rigidbody.velocity = transform.forward * currentSpeed;
the last gif is from my actual project, however it relies on dirty tricks, like forcing (lookAt type of code) to put the plane back in alignment, it causes issues with the other parts of the physics like areodymics etc
tulip marten
it's all going to be very sensitive to order issues
like what order you apply rotations in from which places
so for the sake of making things easy on yourself
transform.rotation *= some quaternion
will be a local space rotation, and the vectors will make sense the way you have authored it - vector3.forward when doing *= will perform a rotation about transform.forward
however, the rigidbody is a significant piece of complexity
so it sounds like you want the plane to be a rigidbody
then you have to do everything physically
in that case, you will have to express the desired state and use a PID controller
so essentially an autopilot. it will be tasked solely with keeping the plane rightside-up
and its input would be roll
this is fine, and is actually pretty consistent with many people making physics based vehicles
if you use the pid controller, you will eliminate all bugs, in a sense, but you will have traded knowledge of unity tricks for knowledge of pid controllers
which like, i don't know the first thing about implementing a pid controller from scratch lol
@echo stirrup is this helpful?
personally, i would not simulate actual roll in physics, since this is 2d. you would have a rigidbody and an rendering hierarchy which are separate
the rendering hierarchy will deal with stuff like orienting the plane in a stylistically / aesthetically pleasing way
the rigidbody could be an ordinary sphere, and it is pushed around with impulses and physics, and is fixed to move along the yz plane
it's a little tricky to do this "right" with a pid controller because the plane is actually confined to yz, and physically, that would mean conserving all momentum along the x axis - moving it will cause other problems.