koobas.hobune.stream
Calculate Force needed to push RigidBody to desiref position
I'm actually working in 2d, but still. Lets say I have a RigidBody and I need this body to "jump" to some position. I used to deal with it by calling
RigidBody2d.MovePosition(desiredPosition);
But this way prevents physics calculations, so if any obstackles is on the way, them wont even slow this body, and I don't want that.
I would use a force controller
Vector2 diff = desiredPosition - rb.position;
rb.AddForce(diff * Time.FixedTime * multiplier);
Clamp diff if necassary. Hope that helps.
This is incorrect. MovePosition simply calculates the velocity required. It won't reach the position if it collides.But this way prevents physics calculations, so if any obstackles is on the way, them wont even slow this body, and I don't want that.
Well, it's true, if body collides with static obstacle it'll stop, but any other object will be pushed away and won't slow moved body even a bit
I'm not sure what you're seeing or why. I did the 2D physics implementation for Unity so I can tell you that $$anonymous$$ovePosition does only three things:
Temporarily set linear drag to zero
Calculate and set the Rigidbody2D linear velocity to something required to move the distance in a single physics update
When move is complete, restore linear drag and previous linear velocity
This means it will collide with stuff and there's nothing stopping it being affected itself. $$anonymous$$oving instantaneously means the temporary linear velocity may be quite high so, depending on its mass it may not be affected much. It can seem as if it's not affected.
You can write your own $$anonymous$$ovePosition to verify this:
Calculate the velocity required to move in one fixed time-step by taking the distance needed to move and divide by fixed-time step. This is the linear velocity.
Set the Rigidbody2D linear velocity and set its linear damping to zero.
Next fixed-update, restore the linear velocity and linear damping
If you do the above, you're doing what Unity does to the Rigidbody2D (ignoring a few $$anonymous$$or details).
Not saying you're imagining things, just trying to narrow it down a little for you.
This looks to me like it's likely to be the key to @DeadCow_'s issue...
$$anonymous$$oving instantaneously means the temporary linear velocity may be quite high so, depending on its mass it may not be affected much.
What it's saying is that while $$anonymous$$ovePosition doesn't stop the physics engine from doing its stuff, if the distance involved is significantly greater than the object might otherwise be expected to move in a single frame, then one shouldn't expect the results to look "normal". It's getting abnormally high momentum, so one should expect it to push things out of the way which under normal circumstances might have a bigger effect on it.
So I would suggest doing what $$anonymous$$elv$$anonymous$$ay says and implement your own version of $$anonymous$$ovePosition, but have it set the velocity so as to move the object over a configurable period of time rather than a single frame. Then you could tweak that duration to get the velocity down to something that produces the kind of physics reactions you're looking for.
You could also try adding in something to reduce the mass of the object while this motion is in progress, to offset the effect of the high velocity on its momentum.
What MelvMay says is correct - MovePosition does pretty much what you suggest. However if you're calling it every frame, the perceived effect might be that it is infinitely strong - i.e. can push anything other than static objects out of the way. This would be because you'd be 'correcting' the velocity of your object every frame, so it would never stray far from the correct location and ultimately end up nudging anything out of the way to do so.
Its worth noting that 'MovePosition' does a little more than you (might?) though it seems unlikely to be part of your problem. It resets the linear velocity of the object before the next fixed update. You could try rolling your own without this functionality. The algorithm is
new_velocity = offset_to_move_by / Time.fixedDeltaTime
Again though, if you do that every frame you'll ultimately see your object push anything pushable out of the way.
And just as a side note, as the original question asked about 'forces'. All a force actually does is change the velocity of the body (as in they literally internally just add a number to the velocity based on the mass and time step), so the above 'calculate different velocity' solutions are equivalent to calculating a force.
Yes, I call $$anonymous$$ovePosition on every FixedUpdate while jumping, calculate position offset based on desired destination and time needed for this "jump". That is the reason I want to calculate required force, to apply in once and leave physcs calculations to the engine.
I think you need to do something like what I suggested in my comment above.
I mean stop using $$anonymous$$ovePosition and ins$$anonymous$$d, just calculate the velocity required to move to the desired position in the required amount of time and apply that velocity (and remove linear drag), just the once rather than repeatedly. So rather than
new_velocity = offset_to_move_by/Time.fixedDeltaTime
you'd have
new_velocity = (final_position - start_position)/duration_of_move
Bearing in $$anonymous$$d wibble's comment about forces above, this is equivalent to what you're asking for - the force you need to apply to to move the object a certain distance (in a certain amount of time).
You'd also need something (in update or a coroutine) to reset the velocity and linear drag once the object has reached final_position (or once the duration has passed, because seeing as you want things to slow it down, there's no guarantee it'll get there).
Alternatively you could leave the linear drag alone and factor that in to the velocity calculation, then you wouldn't need to do the endpoint check. It depends on what effect you're after.
Well that makes sense then. Calling $$anonymous$$ovePosition every frame is very 'powerful' - its like you're reapplying the forces to get to the desired target position every fixed update, of which there are many.
You might be better off just tuning a force that gets applied each frame while jumping, and falls off to 0 fairly quickly. The simplest is a single impulse applied when the player hits jump. This'll require some tuning, but will give you the effect you desire.
This is similar to what Bonfire Boy suggests, though his algorithm, while in the right direction, won't quite nail it as it doesn't account for gravity. You could modify it to do so, but I'd recommend just fiddling with the numbers till it looks right!
Ah yes, fair point about gravity. I'm working on a 2D game with physics that's top-down,so it didn't occur to me.
Fiddling till it looks right definitely seems like the right approach.
