Smooth Movement Test Application (2D, WebGL)

I admire the effort you've put in to make this a useful demonstration of the features.

One thing I saw that I'd like to correct if I may:

This is incorrect and/or misleading. Setting transform.position does nothing apart from setting transform.position. It doesn't modify the body at all until the simulation is run or if you call Physics2D.SyncTransforms explicitly (avoid!) or if you've got Physics2D.AutoSyncTransforms on (avoid!) and call any query or property in which case sync-transform is first done. With that option off, the Transform is what you specified but the body won't be in that pose.

Internally when a Transform is changed, the physics systems (or any more internal system) doesn't get any kind of callback to know that happens. This is why we perform a transform-sync prior to executing the simulation.

For ultimate smooth motion with physics sacrificing some performance and reduced determinism, updating the physics simulation per-frame is better using Physics2D.Simulate. This'll be a lot easier when the following lands too: https://twitter.com/melvmay/status/1164591679535497219?s=20

Can you explain what you mean by this? Are you referring to the fact that interpolation is interpolating from the previous pose to the current pose therefore it's behind where the current pose is? In that case you could use extrapolation which uses forward-velocity based estimates.

Again, wanted to add that it's very cool that you took the time and effort to produce something like this to help others. Ping me if you need any more info or help with it either here or message me directly.

 

That's a good summary but I wanted to reemphasize the problem with

Again, when you do this it does not update the rigidbody.position! If you have Physics2D.AutoSyncTransforms on (off by default) then a transform sync happens anytime you try to read some state from a Rigidbody or Collider so it might look like it updates it but it doesn't, you pay the cost anytime you read state again and again. What happens is that any body/collider registers with the transform system that it needs to know about updates. We can ask at anytime if there are any relevant changes for these components to transforms. This is transform-sync as we are returned which GameObjects and we process updates appropriately. It's pretty fast if there are zero changes so doing transform-sync prior to any read operation isn't bad but if you are making lots transform changes then...

Of course with this off (again that's by default) then you'll see the body/collider isn't updated. You should always have this setting off, it's only there for legacy behaviour.

Note that explicitly setting the position of a body results in all its contacts being destroyed. They'll get recreated during the next simulation step.

If your game requires the physics sync'd to the framerate and interpolation discrepancies is important then I'd say seriously consider running the physics per-frame. In the twitter post above where you can select per-frame and it'll automatically be executed then, it also knows that interpolation is not required and will ignore any interpolation option you set on a Rigidbody2D.

Well MovePosition doesn't modify the velocity of the body so extrpolation has nothing to extrapolate.

I'm confused, these are not "movement types". Giving a body velocity directly or indirectly via a force doesn't in itself cause stuttering so the statement is very misleadings to be honest. Running in the editor causes stuttering, stuff running on the local machine causes stuttering etc. In no way does a constant fixed-update of Transform position causes suttering in itself. For instance, setting a Transform position to move at a constantly velocity each frame is no different than doing that on a rigidbody. Same goes if you did both of those during a fixed-update.

The thing to watch out for and I want to emphasize this isn't the physics system (2D or 3D) is that fixed-update can be called multiple times per-frame which will mean you get multiple physics steps as well as other things that run in the fixed-update. This normally only happens though if the game-time is lagging, perhaps due to poor frame-rate etc.

Also, the default fixed-update time of 50hz is bonkers. I am not sure who came up with that originally but it's nonsense. It should be set to 60hz which would mean less likelyhood of the fixed-update time-base being out-of-sync with the game-time i.e. fixed=update on a 1:1.

Sorry for the inconcise rambling above, kind of typed it as I thought of it; hopefully you can pick out useful stuff from it.

Feel free to ping me if you need anything specific.

 

I missed this part. Basically yes, do everything that you previously did during fixed-update in update. Also note that you can run the simulation before "Update" is called or after "Update" is called by simply calling the Physics2D.Simulate in a monobehaviour that's had its execution order set early or late. This can be handy depending on whether you want to set up stuff then simulate or simulate and then look at results and respond for next frame. Running the simulation early can be good if you're only setting velocities, adding forces etc. If you're setting positions directly (ugh!) then you'll probably want to run the simulation after but before rendering.

 

It's not odd at all. If all it did was set the velocity to move to that position in one time frame then it'd still have that velocity and not "move to that position" but carry on past that position. For large positional jumps, this velocity can get very high indeed.

MovePosition needs to be superior to just setting the position because that can cause collision tunnelling because it just instantly teleports to that position. MovePosition temporarily sets the linear velocity required to move to the specified position over a single simulation step. It does this by storing any existing linear velocity and linear drag and assigning the internal velocity. When the simulation runs it uses this internal linear velocity to move to the position and this means it moves through the interviening space and collides with everything along the way. When the simulation step has finished it reassigns the stored velocity.

If you call MovePosition but the body already has a non-zero linear velocity, this will be restored when the simulation step has finished. Also, if you read the linear velocity it'll be the stored linear velocity; the calculated one for the MovePosition is completely hidden from you.

Kinematic bodies will always get to the specified position. Dynamic bodies won't necessarily get there if they collide. Collisions along the way work for both body-types.

You can obviously implement your own MovePosition which is just (distance vector / time-step) and you'll need to save/restore any linear drag. We implement this for you so you don't have to deal with all that nonsense.

Yes, that's expected as you say. The way I like to explain it to anyone is that interpolation is based upon the past facts but extrapolation is based upon a guess of the future.

You're most welcome. I'd be interested to see what you think of running the simulation per-frame; hopefully you'll never want to use anything else after trying it.

 

When I implemented MovePosition it made complete sense to not just have it modify the velocity otherwise it's a MoveToPositionThenContinueOnInThatDirectionUnlessISayStop. This just isn't something that made sense and indeed, when initially it was implemented there was a bug where the velocity wasn't restored and we had a lot of bug reports for it which makes sense.

In the end, if you're doing step-wise moves from position to position but may not want to continually move to a new position then MovePosition is perfect. If you want to modify the velocity permanently of your body to do the same then that's trivial to do yourself as I mentioned above with velocity = (direction vector / time-step) and choose whether you want linear drag or not as this can affect it. In the end, no method can do everything for everyone but as long as what it's actually doing is available to do yourself in a simple function then it's all good.

Personally I think all of the above conversation is just highlighting all the horrible hoops a developer has to jump through to fight the problems of running physics at a fixed time-step as opposed to a variable time-step. Input, visual interpolation, queries etc.

I do think that a lot of games and devs should just use per-frame physics updates and completely ignore the fixed-update stuff. In many cases it's simply not relevant or in the very least, my way to sell it would be that when you start learning this stuff, the fixed-update stuff is a confusing distraction. Like learning to drive while the instructor explains details of the internal combustion engine.

My hope is that in the future we'll see more per-frame physics stuff in video tutorials. Should be easier for beginners now that it's a simple option with no scripts required.

 

Just to note, as I mentioned above somewhere in the wall-O-text so easily lost, Box2D doesn't have any concept of this. It's purely a construct of Unity code and is there as a convenience function to something you could easily do yourself in scripts, say an extension method etc.

 

It's just a matter of when stuff happens, something which you don't mention above.

So you say when you set the Rigidbody position directly you don't get any "lag". I've never liked this term as it's vague. I can only presume you're doing this per-frame and not per-fixed update (which by default might happen less frequently). It should be obvious then that this means the RB position is always (per-frame) at the position you specify so in your terms, there's no "lag". The downside is that as soon as you issue this command, all contacts are destroyed, you can cause collision tunneling and it isn't compatible with interpolation (it actually cancels interpolation until the next physics update). Depending on the bodies/colliders/effect-you-want these may or may not be issues.

When you use MovePosition it just tells the physics system to calculate a move to that position for when the physics system updates. It's only actioned when the simulation step occurs. Again, I can only presume you're doing this per-frame which means you'll (potentially) call it several times before the physics actually updates and the last one called will be used when the physics (fixed-update) step occurs.

In the end, the physics is running at a fixed frequency that isn't in sync with the frame-rate which could be much higher or lower. You need to understand if a function has immediate affect (like setting a position of a RB) or only gets actioned when the physics system steps (like MovePosition on a RB).

Interpolation is just a function that doesn't affect physics, it's only job is to update the Transform only (nothing in physics is changed, especially not the RB) from the old RB position to the current one. It's a pure visual feature and has no impact on physics calculations. It's there simple because by default, physics does not run in-sync with the visuals.

You can ignore all of this and never use interpolation again if you simply perform a manual simulation step per-frame using the frame-delta. If the physics in your game is happy with this variable update rate on physics then it makes everything simpler as the physics is always in-sync with the visuals.

In the future you'll be able to just switch to per-frame physics updates in the settings without any code changes: https://twitter.com/melvmay/status/1164591679535497219?s=20

 

The ability to select fixed-update, update or script for physics simulation has been in since 2020.1.0a3 so you can get it now (currently 2020.1.0a21).

Note: 2020.1.0a21 also contains a fix that allows Rigidbody2D.MovePosition/MoveRotation to work with any time-step (fixed-update, update or arbitrary step via script).

 

Yes but it's been a very long time since 50hz monitors were a thing and a typical refresh is 60hz. Unless you're vsync it won't match anyway but even if you are, it might still drift slightly because the fixed-update is using a software counter and rendering is using a hardware one (vsync). It's totally up to you if you want to try to match the two.

The problem with 50hz on vsync 60hz is that it's not just slightly off, it's a lot off so it drifts and causing highly periodic double fixed-updates to be called.

Surely you already know this because by default it's running at 50hz so you're asking if it reducing to the default would be bad.

Interpolation smooths out the differences between larger interval jumps if you've still got a decent frame-rate.

You have not described your set-up here though, you're kind of making statements without context so I'm left to guess what you mean. Anything I say is a guess on how you're set-up. If you're using vsync (you mention a strict 120hz so you must mean with it on) then it's a far more accurate clock than the software-based fixed-update so if you're running per-frame physics, it'd be a strict 120hz so there's no reduced determinism. If you're not using vsync then yes, it'll be variable physics updates but as the refresh rate (120hz) of your monitor makes no difference to the rendering rate. The fact you say it reduces determinism suggests you're not using vsync and are just referring to the refresh rate of your monitor which at that point is about as relevant as the sampling rate of your mouse.

 

I wanted to add: When using per-frame update option in 2020.1+, it automatically ignores any Rigidbody2D interpolation because it's not used. Prior to that it's not turned off so if you're manually updating per-frame, you should turn that option off on all Rigidbody2D.

 

You're spending more CPU time running physics per second so you'd have to determine if that is adverse for your device. Beyond that there's no downside.

You'll get diminishing returns as you increase the frequency. For a lot of game-play types, you'll get zero benefit in doing so i.e. shoot em-up's etc.

It's generalised as saying higher frequencies give "better" or "more accurate" physics as if that is the ultimate goal. In the end, it'll mean smaller simulation time-steps. This will result in reducing chances of discrete col-det tunnelling, curved motion might be closer to the continuous curve you might expect etc. Some of this you're likely not to have a problem with at lower frequencies. For fast moving stuff (bullets) you can use use the more expensive continuous col-det on them only rather than using discrete col-det and running the whole simulation at a higher frequency.

In the end, use the profiler but make sure you're not wasting CPU cycles unless you have a clear benefit.