Mathf.Clamp doesn't quite clamp correctly

During the mini-challenge in the previous lecture I created the following code:


This handles the movement for the player ship and restrict it to the screen boundary (as covered in this lecture). I can continue with the lecture using the code shown but I’m curious as to why this doesn’t work fully. The ship moves as expected but when the edge of the screen is reached it actually moves past the clamped boundary x value (6.2) by 0.2. So despite the Mathf.Clamp, the ship will move to 6.4 while the movement key is held. Once the key is released the ship moves back to the clamped value of 6.2. It’s not a major issue but it is unexpected behaviour and I’m curious as to why it’s happening. Any help would be much appreciated.

1 Like

After a fair bit of reading around I got the code working the way I wanted. Working version below:

I’m still not entirely clear why this works and the version I had before didn’t. If I had to guess, I think it’s because I was using a Rigidbody component and altering its velocity rather than addressing the Transform component position directly. I’ve also asked the question on the Unity beginner forum, if I get an answer I’ll repost here in case anyone else runs into similar issues and wants to know…

1 Like

For the clamping code. Are you reading the higher code directly from the inspector, or via the debug log to console?

1 Like

If by Adam’s space shooter, you mean the tutorial here: https://unity3d.com/learn/tutorials/projects/space-shooter-tutorial, then yes. I ran through a number of those tutorials before I found this course. The code in the original post is very much derived from that Space Shooter tutorial.

I’ve read the values for position and velocity from the debug log and the inspector. Both match up.

1 Like

wierd, theyre both in the same loop during that timestep.
im making my way home just now, so ill have a look when i get back to terra firma and my laptop for a test.
ill get back to you later today Ralph.

2 Likes

Thanks Obo. It’s not critical as I have a working solution now but I am interested to find out why the first piece of code I wrote had this odd movement aberration. Appreciate the assist. :slight_smile:

1 Like

This probably happens because the internal physics calculations happens just after the FixedUpdate runs.

Take a look at this reference:
Execution Order

This is what seems to be happening:

1st You address an velocity to the rigidbody on fixedupdate;

2nd Then you clamp the position right after addressing the velocity (which changes the position but don’t change the velocity);

3rd Right after that, the engine calculates the physics which includes the rigidbody velocity and move it accordingly (which causes the aberration that you described since nothing is clamping it after it moves);

if my theory is correct, then another possible way to fix is by moving the clamp to an IEnumerator yielding the result after the physics calculations using a coroutine inside fixed update to call it:
WaitForFixedUpdate Coroutine

Updated Wed May 03 2017 11:56

Yes, just tried and this is indeed the reason.

Solution - Just add this to your original code and it should work as expected:

	void FixedUpdate()
	{
		// ADD THIS TO YOUR FIXED UPDATE
		StartCoroutine (WaitForFixed());
	}

	IEnumerator WaitForFixed()
	    {
		    yield return new WaitForFixedUpdate();
		    transform.position = ClampingMethod(); //PUT YOUR CLAMP HERE
	    }
2 Likes

Brilliant. I totally get why this is happening now. Also picked up a little bit more Unity-Fu into the bargain. Thanks. :slight_smile:

1 Like

I’ve seen this thread yesterday but I wasn’t understanding why this was happening either, so it also helped me to pick up a little bit more of Unity-Fu too now that we’ve found the problem xD

It is very good when users bring those discussions to the forum, it is a good opportunity to learn more about how unity works! Keep it up :smiley:

2 Likes

Privacy & Terms