koobas.hobune.stream
Mathf.SmoothDamp's smoothTime faster at 0 than negative?
I have trouble with my FPS leaning function. When my camera was leaning to the side a collider with a rigidbody should detect collision.
but for some reason when I was leaning to the right side it looked like the collider detected the wall to late and I was looking through the wall. but when I was leaning to the left side it stops almost instantly.
after... now 2 or 3 hours I found out that it was not the collider but it was the SmoothDamp function that causes the problem. info: When the Collider hit a wall it tells the SmoothDamp that the target position is the current position.
after I unhided the smoothTime of the Mathf.SmoothDamp function in the script it was obvious.
When I lean to the right side the smoothTime is a positiv number and when the collider hits a wall it takes sometimes more than 1 second till the smoothTime is 0. When I lean to the left the smoothTime is a negative number and when I collide with a wall the smoothTime is instantly at 0.
I maybe find a work around but is this normal? or is this a Bug in Unity?
smoothTime Approximately the time it will take to reach the target. A smaller value will reach the target faster.
so your number that is smaller than 0 which is the smallest amount of time it could take.
Is taking less time to reach the target than your other number which is greater.
A greater value taking more time.
Sounds like its working as intended
lol nice joke :). I thought the smallest value is 0. when I have a negative number to reach like in my case then the smoothTime is at the beginning like -1.253254 or so. and as closer you come to the target value so the smoothTime will be smaller. In my case the moment the collider hit something the current value and the target value are the same sooo it should also set the smoothTime to zero because it is already there where it should be! and I dont get it why it has still 0.00434 smoothTime for a second or so...
because you miss the target most likely. The odds that you are perfectly on target as you move are exceedingly unlikely.
At the end of the day your moving, and movement is really like a motion picture. Its a bunch of discrete movements done really fast. But those discrete movements are in fact basically teleporting. You teleport just a little past the target, and then it tries to correct.
What you need to do is something like
if vector3.distance(object.transform.position, target) < .001
smoothTime = 0;
or if (mathf.approximate(objet.transform.position, target) smoothTime = 0;
Allow a small leeway.
I did something like that already but this is still odd. it should not matter if you have a negative target or a positive target. I know that logically it could not go perfectly to the target and it will compensate. but I am already at the target. current = target in my case. so why still moving when its perfect there. with negative it works with positive not...
