Snap grab rotations to cube normals

[Deconimus]

As discussed in PR #31, specifically this implements "step 1" from this comment.

All grabbed objects are now rotated towards the player according to the closest cube normal facing the player. The calculations with the surface normals are done only once per grab, after this the relative rotation is preserved. Right now, the normal snapping is done in playerSetGrabbing(..) which is a bit bulky, but this will change with the planned future refactorings. Per frame the impact is only one additional quaternion multiplication in playerUpdateGrabbedObject(..).

Related refactorings:

• Added playerPortalGrabRotate(..) in addition to playerPortalGrabTransform(..), since a point transformation is not always needed.
• Similarly, added collisionSceneGetPortalRotation(..) to collision_scene which is a lot simpler to compute. Only utilized in playerPortalGrabRotate(..) so far.
• playerGetMoveBasis(..) now takes a Quaternion instead of a Transform struct as first parameter, since only the rotation was used in the first place. Calls where we just want to calc the forward-facing dir vector relative to a given rotation are now simpler (e.g. in playerThrowObject(..)).

[Deconimus]

I noticed object rotation will not be "cancelled out" as before, if the object-space upwards direction of an object was rotated in world-space before the grab. This would've been consistent with my former goal of source-like behavior but isn't helpful here.

I'll have to update playerSetGrabbing(..) accordingly.

[Deconimus]

The cube normal snapping is now reworked to snap the closest normal towards the player while also considering the object's relative upward direction. This way, the grabRotation should now work just the like the previous implementation minus the superfluous rotations.

While searching for bugs and cornercases, I've found #52, which is unfortunately unrelated to the rotation here and instead a bug of the grabPoint transform introduced in #35.

[mwpenny]

I noticed object rotation will not be "cancelled out" as before, if the object-space upwards direction of an object was rotated in world-space before the grab. This would've been consistent with my former goal of source-like behavior but isn't helpful here.

Can you explain this issue a bit more? Through looking at your changes and trying it out before/after the follow-on fix I was unable to reproduce what I thought you were talking about. So I think I'm misunderstanding.

[Deconimus]

Can you explain this issue a bit more? Through looking at your changes and trying it out before/after the follow-on fix I was unable to reproduce what I thought you were talking about. So I think I'm misunderstanding.

Before the fix, grabbing a cube which relative top/bottom sides weren't parallel to the world XZ planes resulted in buggy behavior. E.g. when throwing a cube in the air against a wall or pushing it against a wall while still grabbing it so that it rotates.

Here's a direct comparison:

grab_rotation_bug.mp4

grab_rotation_fixed.mp4

[mwpenny]

Thanks. Your comment about Source-like behavior makes more sense now too. Good catch!

[mwpenny]

Thank you for this. It is a noticeable improvement to how the game feels.