So, as a beginner, I followed this tutorial about developing a first person camera, and there the person used a clamp to limit the vertical rotation of the camera to 89 ad -89 degrees. Well, when I tried that out when I slightly move my mouse, all I see is the screen flickering between the sky and the blue horizon as if my sensitivity is super high and the mouse is automatically moving. Here is a screenshot of my code:

This problem occurs only when the clamp line is present, other than that it works as intended (well, except for the vertical camera limit).

I'd be grateful to any kind of help provided

I would try printing the variables. That might help diagnose the problem.

Welcome to the forums @Phil_Violated!

My guess is that it's probably due to how Godot handles rotation over 180 degrees. My hunch is that when the Y rotation is over 180 degrees and the X rotation is around 90, it will flip it from 180 to -180 on the Y, which could be affecting the X axis too. That is probably why the clamp is causing it but not the rotating, since the rotate_x function just adds an offset and so it doesn't matter if its positive or negative. You can see this if you rotate an object in the Godot editor on multiple axis, rotating one over 180 will flip it to negative and this can also flip/change the rotation in the other axes as well.

I agree with DaveTheCoder though, I would suggest printing the values and seeing if the numbers help show what is causing the issue.

If the issue is that the rotation is flipping when over 180, then I might suggest parenting your Camera node to a Spatial, and then rotate the Spatial on just one axis and the camera on just the other axis. That way, the rotation shouldn't have the issue where it suddenly changes when one of the axes gets over 180, as one one axis is being modified at a time.

@DaveTheCoder said: I would try printing the variables. That might help diagnose the problem.

Well, apparently, the clamp doesn't work, the print command executed even after I let go of the mouse

@TwistedTwigleg said: Welcome to the forums @Phil_Violated!

My guess is that it's probably due to how Godot handles rotation over 180 degrees. My hunch is that when the Y rotation is over 180 degrees and the X rotation is around 90, it will flip it from 180 to -180 on the Y, which could be affecting the X axis too. That is probably why the clamp is causing it but not the rotating, since the rotate_x function just adds an offset and so it doesn't matter if its positive or negative. You can see this if you rotate an object in the Godot editor on multiple axis, rotating one over 180 will flip it to negative and this can also flip/change the rotation in the other axes as well.

I agree with DaveTheCoder though, I would suggest printing the values and seeing if the numbers help show what is causing the issue.

If the issue is that the rotation is flipping when over 180, then I might suggest parenting your Camera node to a Spatial, and then rotate the Spatial on just one axis and the camera on just the other axis. That way, the rotation shouldn't have the issue where it suddenly changes when one of the axes gets over 180, as one one axis is being modified at a time.

Okay, so before I saw your message I already found an alternative but similar code which worked fine with the clamp, but I still decided to give your suggestion a try, I tried printing the rotation.x values and it was printing just 0 no matter what my input is. I was getting a stream of 0's in the debug window, I also added an if statement where if the camera goes above or less than 89 or -89 degrees, it'd print "Camera's broken" so my debug was just 0 and "Camera's broken". And judging by the 3d view, it appears as if the camera is just looking straight upwards and was locking itself there every time I tried moving it. I tried your suggestion regarding the spatial node, where the x input rotated the spatial and the y rotated the $camera , it was a bit tricky to set up but the results were the same. So I found this new code which works fine:

I don't know if I should mark this as an answer since this was more like getting around the problem instead of addressing it.

2 years later