# (3D) MoveTowards Speed Decays as Destination is Approached on a Terrain

I haven’t been able to find a good answer for this - I want to move an object towards a variable destination at a constant speed on a terrain

I have a coroutine for this movement that essentially executes the following in a loop:

``````Vector3 newPosition = Vector3.MoveTowards(
currentPosition,
destination,
speed
);

newPosition.y = activeTerrain.SampleHeight(newPosition);

someObject.position = newPosition;
``````

Everything works as expected until `someObject` begins to approach `destination`, at which point the rate of movement decays to the point where movement is no longer noticeable and `someObject` never reaches `destination`

I’m able to determine the rate of this decay by measuring the distance of `currentPostion` to `destination` on each loop iteration and comparing it to the distance measured on the last loop iteration

I’m fairly certain this decay has something to do with setting the y value to the active terrain’s height, but this is movement on a terrain so it needs to be done

so what am I doing wrong here? what’s the correct way to use `MoveTowards` on a terrain? or should I be using a different technique to move an object towards a destination (at varied distances) at a constant speed on a terrain?

NOTE: I considered using a navmesh approach, but this movement is for temporary scripted control of a first-person player character to move a relatively short distance, so I thought baking a navmesh might be overkill just for this particular movement - but perhaps it’s the only way?

Most likely the “destination” is below your mover. For a simplified example, picture being at (1,10,0) with your destination being at (0,0,0), and the terrain height being 10 tall. You move towards the destination by, say, 5 units, which here is mostly “down”, but then you set your Y to the terrain height, and suddenly you’ve lost 80% of that movement, and you’re now at (0.8, 10, 0).

If you’re not intending to have this control the Y position (which is being controlled by the terrain), then just write your code such that the Y position of the destination doesn’t matter. Most likely you could fix it by simply setting destination.y to currentPosition.y before you call MoveTowards. If that feels too hackish, you could calculate your movement direction, set its Y to 0, normalize it, and then multiply by your speed.

1 Like

@StarManta that makes total sense… the `MoveTowards` calculation obviously isn’t aware of the y value that I’m changing after-the-fact, so I lose that percent of progress on the next iteration of the calculation, which is the decay in progression that I’m seeing

keeping the y value constant during the calculation yields the constant rate that I was expecting, and I reason this is a viable solution in my case because I only want `MoveTowards ` to drive the x and z values*, y* is driven by the terrain height