I mean I agree, I just can't isolate what code could be causing it? Either way there's clearly something up with the rotation and it happens specifically when the mouse is wiggled vertically up and down enough, I'll use print and see what's going on a bit in more detail. The thing is I tried commenting out sections and the same thing happened on my end which is pretty odd.
Lethn It's pretty clear that your "up" axis, or Y rotational basis is getting whacked somehow. I upped the camera sensitivity to .7 and went crazy on the mouse and still could not reproduce.
But here's a fun bug with my gremlin getting caught on a tree leaf and having it's up axis get jacked up thanks to wonky collision:
OH! I just thought of something extremely unlikely, could it possibly be my mouse's DPI? I'm going to have to test this.
Edit: Nope nevermind, still managed it, I do wonder if it's a hardware issue though now I think about it, we need some testers lol.
Lethn Is there any chance at all you're colliding with something? The point of my video was to show that collisions themselves can affect the Y access of the parent object and screw up the total rotation of the player (of which your camera is attached to). I don't know why shaking the camera like that would do that though.
That's a good idea! I'll double check but I'm not sure how this could be the case, the camera and mouselook node shouldn't have colliders attached to them unless I've messed up somewhere so it could be a parenting issue? I'll do some poking at it and see what happens.
That video looks like what would happen if the x and y rotations are both performed on the same node.
For example I can recreate the rolling to the side if I change the code to:
func _unhandled_input(event):
if event is InputEventMouseMotion:
rotate_y(deg_to_rad(-event.relative.x * mouseSensitivity))
rotate_x(deg_to_rad(mouseSensitivity * event.relative.y))
rotation.x = clamp (rotation.x, -(PI/4), PI/4)so both x and y rotations happen to the character controller, instead of x to the mouselooknode and y to the controller.
As long as the character controller only rotates around y and the mouselooknode only rotates around x, that shouldn't happen.
I'd say try logging out the x,y,z rotations of the Player, MouseLookNode and PlayerCamera then look at what they are when the view is twisted. The Player should have 0 for the x and z, the MouseLookNode should be 0 for y and z, the PlayerCamera should be 0 for everything.
(I wonder if something is rotating the camera, which is adding to the rotation of the mouse node)
...... You guys are going to love this, it turns out I had my mouse look node's y rotation set to -180 degrees and that's what was causing the clamp issues, I just didn't notice and @Kojack got it right with the MouseLookNode LOL. Amazing how basic things can screw up your code so royally if you haven't done the setup right, thank you, that issue was annoying me and being very baffling because there was nothing in the code I could see that could be doing it.
Going to have to remember when dealing with my instances to make sure everything's defaulted to 0 before I started placing stuff in scenes. I'll try not to celebrate too soon and make sure to keep testing but holy hell that was frustrating.
Edit: Yep, confirmed fix now it happens when I rotate the player itself in the scene too, so I need to rotate the scene if I want the player pointing the right way I think that's where I've been scewing up the rotations.
There's a lot of oddities that can happen with rotations. 
I've seen some engines (or just euler angle classes) that when the pitch goes above 90 or below -90 it flips the entire system. So if you set it to 100 degrees pitched up, it would actually turn into 80 degrees up, 180 yaw (face backwards) and 180 roll (flip upside down). That meant you couldn't clamp a value to 90, because it never stored the larger value. In particular that can happen if the engine only gives you quaternions and you manually turn them back into angles.
Gimbal lock is always so fun to debug, isn't it... /s
I know it's pretty old topic, but me and my friend trying one of Lukky's Godot tutorials, from youtube. And he did camera rotation for 3rd person view, but without any rotation limit. I googled and found how to that with clamp, but quickly noticed that rotation become broken if I move mouse too fast vertically. Camera leans a bit, and Mathf.clamp stop working. I displayed rotations on a label, and noticed that Y axis changes after quick movements of mouse.
I noticed that this happens only when I do:
Vector3 camera_rot = camMount.Rotation;
camera_rot.X = Mathf.Clamp(camMount.Rotation.X, Mathf.DegToRad(-70), Mathf.DegToRad(70));
camMount.Rotation = camera_rot;So it's became broken, after I copy rotation to temp Vector3, change it, and then return values back to Rotation property.
It's my first game engine that I try, and I barely coded anything complicated, before, or what's required actual math, so I'm really was confused why this happening. And I'm still confused.
I was able to kinda fix it, by adding
camera_rot.Y = Mathf.Pi;
after clamp.
Now reading this, I see that issue happens because -180deg rotation, and in that tutorial Player base node was rotated 180 Y (and, I guess, I rotated it to -180) , because coordinate system in Godot is different to that from Mixamo or something like that, I'm still not sure.
So I've reset Player rotation to 0,0,0 from -180, and rotated camera to +180.
And now it's not breaking even with craziest mouse moves.
I really wish I able to understand what exactly goes wrong, but even after reading this thread I'm still not sure.
Lethn it's not hardware cause I'm having the exact same problem. have you fixed it yet? if so please tell me how!
Myth_Maker_Foreal Never use euler angles for 3D orientation/rotation. Use bases/quaternions instead. Much easier and free of weird behavior like this.
