Official 2D Physics : Manual Simulation, Simulation Groups & Multiple Worlds

Let me start by saying what I'd like to get out of this thread before going any further; constructive feedback on the thread topic, good use-cases for them, creative ideas on how to ideally expose stuff via components/API etc. What I'd like for you to get out of this is the ability to make real changes in what's coming. I know that sounds like an empty promise but it's true; whilst we already have many sources of use-cases, now is the time for good implementation ideas.

So I'm Melv May and I'm responsible for the implementation of 2D physics in Unity (I'll say "Physics" from now on). I've potentially been the source of delight and frustration for physics for you. It's the Easter break here in the UK but my mind is squarely focused on physics for 2017. Indeed, early next week there'll be a big update to the Unity RoadMap for physics which'll cover a huge range of features and improvements. Some are "planned" and some are research only.

For now though, I'd like to get some feedback on a few select topics and I intend to create more on other topics soon. This is more than a wall-o-text though and for the impatient amongst you, there's a custom build avaiable here that contains implementation for some of the discussion below!

So the topic for today is three things that have some overlap:

• Manual Simulation
• Simulation Groups
• Multiple Worlds

Manual Simulation
So as you know, Unity already performs a physics simulation during the fixed update. Technically, during the fixed update, all the FixedUpdate functions in your scripts are called first. When that's done, the physics simulation is run followed by Unity performing all physics callbacks. I'm going to ignore the fact that Unity can actually perform the physics simulation several times if it needs to catch up with real time but yes, this happens. After the fixed update, we're into frame rendering i.e. Update callbacks etc.

One of the problems with the above is that there is no LateFixedUpdate which means it can be a pain to gather results from the physics simulation unless you wait until the next FixedUpdate.

So, I went ahead and implemented the ability to turn-off the automatic simulation of physics using:

Code (CSharp):

1. Physics2D.autoSimulation = false;

With this done, physics will not automatically update during FixedUpdate. This leaves it open for you to update the physics yourself using:

Code (CSharp):

1. Physics2D.Simulate(Time.fixedDeltaTime);

This means that you can now update the physics whenever you like. It also means you can potentially read the results of the simulation immediately after the call.

To duplicate exactly how the physics simulation is called, you could now do the following:

Code (CSharp):

1. using UnityEngine;
2.  
3. public class BasicSimulation : MonoBehaviour
4. {
5.     private float timer;
6.  
7.     void Update()
8.     {
9.         if (Physics2D.autoSimulation)
10.             return; // do nothing if the automatic simulation is enabled
11.  
12.         timer += Time.deltaTime;
13.  
14.         // Catch up with the game time.
15.         // Advance the physics simulation in portions of Time.fixedDeltaTime
16.         // Note that generally, we don't want to pass variable delta to Simulate as that leads to unstable results.
17.         while (timer >= Time.fixedDeltaTime)
18.         {
19.             timer -= Time.fixedDeltaTime;
20.             Physics2D.Simulate(Time.fixedDeltaTime);
21.         }
22.  
23.         // Here you can access the transforms state right after the simulation, if needed...
24.     }
25. }

For those interested, almost identical functionality has been added to 3D physics and you can find the discussion here although I'd like if it you'd keep 2D physics discussion here if possible. Don't worry though, I'll share discussions with Anthony (the owner that thread).

The manual simulation feature for both 2D & 3D physics is landing in 2017.1b. We feel that this is the basis for lower levels of control and isn't going to change much.


Simulation Groups
With the ability to manually simulate physics, there's an opportunity to perform partial simulations i.e. only a selection of all Rigidbody2D. There are several ways to achieve this, the problem being that supporting all of them could lead to a messy API so it'd love to get some feedback on this.

Here's some potential ways to perform partial scene simulation:

• Layer-based - "Physics2D.Simulate(time, layerMask)"
  
• Selected-based - "Physics2D.Simulate(time, Rigidbody2D[] bodies)"
• Group-based - "Physics2D.Simulate(time, groupMask)"
• Others? Please tell!

The obvious one would be to use layers; they are integrated into the UI, are named and have existing meaning to physics. This would work and is probably intuitive to some degree however there are some oddities here; the layer is against the GameObject and not the Rigidbody2D. This means child Collider2D can be on separate layers. This makes partial scene simulation potentially confusing because partial scene simulation is against Rigidbody2D (bodies) and not Collider2D. We will never only simulate a specific Collider2D as they are not simulated, they only produce contacts from simulating Rigidbody2D. So layers would make sense as long as it was understood that it was the layer of the Rigidbody2D only. Finally, restricting partial scene simulation to layers then adds another meaning to layers which I feel would be overly restrictive in some use-cases.

The next choice is to allow a physics simulation of an array of Rigidbody2D. Here there is no confusion over what will be simulated. I feel that this is a good choice for some use-cases however whenever I see this I start to feel that in some cases, compiling and maintaining this list/array could become cumbersome. It does have the advantage however that you are not limited by any existing mechanism on what gets updated.

The next choice is to provide a dedicated property on Rigidbody2D for this. This solves the potentially confusing aspect of layers for Collider2D above. With the ability to specify a Rigidbody2D.simulationGroup = (0-31) you'd be able to associate a simulation group with some logical aspect of your game and keep it apart from the collision layer mechanism. This means you can manually update the physics simulation for some or all simulation groups. Simulation groups have no name (for now) but that could be added if and only if this were applied to both 2D and 3D physics alike. Simulation groups also allows turning on/off whole groups of simulation even while using automatically physics updates with "Physics2D.simulationGroupMask = <mask>" which is used if you do not specify a simulation group mask when manuallly updating physics or if automatic physics updates are on.

This would look like this.

This would allow you to perform manual updates on selective simulation groups like this:

Code (CSharp):

1. using UnityEngine;
2.  
3. public class GroupSimulation : MonoBehaviour
4. {
5.     // Create 32 simulation groups.
6.     public bool[] m_SimulationGroups = new bool[32];
7.  
8.     private int simulationGroupMask;
9.     private float timer;
10.  
11.     void Update()
12.     {
13.         // Do nothing if the automatic simulation is enabled.
14.         if (Physics2D.autoSimulation)
15.             return;
16.  
17.         timer += Time.deltaTime;
18.  
19.         // Catch up with the game time.
20.         // Advance the physics simulation in portions of Time.fixedDeltaTime
21.         // Note that generally, we don't want to pass variable delta to Simulate as that leads to unstable results.
22.         while (timer >= Time.fixedDeltaTime)
23.         {
24.             timer -= Time.fixedDeltaTime;
25.             Physics2D.Simulate(Time.fixedDeltaTime, simulationGroupMask);
26.         }
27.     }
28.  
29.     // Calculate the simulation group mask.
30.     private void OnValidate()
31.     {
32.         simulationGroupMask = 0;
33.         int i = 0;
34.         foreach (var group in m_SimulationGroups)
35.         {
36.             if (group)
37.                 simulationGroupMask |= (1 << i);
38.  
39.             ++i;
40.         }
41.     }
42. }

Experiments!
So as I mentioned above, the ability to manually update physics is going into 2017.1.0b soon. On top of this, I've implemented the "simulation groups" option above as an experiment on top of that. Right now, the simulation groups are a 32-bit bitmask which is both fast and easy to implement. It's possible to allow an unlimited number of bits but that incurs extra cost but isn't prohibitive. Right now, it's just a quick experiment.

The good news is that this is now available as a one-off custom build here.

I also made some posts on Twitter if you do that kind of thing:
https://twitter.com/melvmay/status/852440222348578817
https://twitter.com/melvmay/status/852915614570209280
So right now, manually simulating physics outside of play-mode in the editor isn't allowed however I'll soon allow that. Do not forget to install this into a separate folder. Also note that whilst it's badged as 2017.1.0b2, it isn't that release, it's just partially based upon that and certainly should not be used for production. You have been warned.

Beyond that, I'd love for you to download it, experiment with it and discuss!


Multiple Worlds
So I decided to include this alongside manual physics simulation as I believe there are many overlapping use-cases.

Right now, we offer a single physics world. Everything is exposed as components that automatically create the low-level physics objects for the implicit single world we create when Unity starts. This is simple and in most cases, all that is required however it isn't perfect and does not help when you want to start doing more advanced stuff.

Rather than state all the known use-cases for multiple words such as isolation, prediction etc, I'll skip that and go ahead and discuss how that feature might emerge but more importantly, involve you in the problems in exposing it.

So right away, we have a few problems with the notion of multiple worlds. It's not a problem creating these worlds, more a problem of "fitting" them into the existing API and component-based setup.

The first problem are components; when you create a Rigidbody2D, Collider2D or Joint2D, it's created within the default world. If we were to expose the ability to add multiple worlds, we'd have a problem with these components as we wouldn't know which world to create them in. Sure, we could expose a property on each that allows you to change it but that would mean creating it in the default world, you changing the world then it being deleted and recreated. This is crazy wasteful. Changing the generate "AddComponent<T>()" to take a physics world wouldn't fit correctly and just isn't an option.

We could make the world itself a factory for components by adding specific factory methods like world.AddRigidbody(gameObject), world.AddCollider2D(gameObject) etc but it's an ugly syntax.

When a GameObject is disabled, we do not create the underlying physics objects so it's possible to assign the associated world with the component before the GameObject is enabled but being forced to do this with the only alternative being creating by default in one world to then have to change it is not good.

Another problem is persistence. If we were to create a component associated with a world and that component was persisted in the scene or part of a prefab then that requires the world to do the same. This means that worlds cannot be freestanding and must be part of a global setup saved with the main Physics2D state for the project.

Another problem is with the existing Physics2D type. This is a static type that allows you to both change the settings of the default world and perform physics queries on it. Changing every single query to allow a world instance arg is a lot of work and leads to lot of overloads and potentially confusion. The existing settings would have to be deprecated and moved to some world instance.

Another issue is callbacks; when you had a callback, the callback signature does not tell you which world. This can be easily worked around by exposing the world instance on the Rigidbody2D & Collider2D.

One solution is to allow context switching i.e. the ability to select a world instance as the current context. This means you have a physics world object and select it as the current context. Then, any new components added or physics queries issued relate to that physics world in context only. This isn't perfect but does solve several issues. A real downside here is that it can lead to subtle bugs in scripts where the context isn't set so the last set context is used. These would be hard to track down.

Another solution is to ignore Physics2D and all existing components completely! This would mean exposing managed types that allow creating a world, body, collider & joint primitives. Indeed, work this year that'll appear on the road-map is to expose lower level primitive shapes for colliders that represent an almost 1:1 of what physics actually uses at a low-level. The downside here is that you'll only have multiple worlds as a script-only feature with no components or the ability to use effectors etc. A problem with this is that these would require their own callbacks as they could not use existing ones as they are clearly based upon Rigidbody2D and Collider2D components.

Conclusion
Enough text already!

So I would really appreciate thoughts on this. If you could focus on these topics only, it would also be appreciated. If you would desperately like to discuss another feature request then reach out to me and I'd be happy to start another thread.

 

Yes and as I said above, there's going to be a large update to the road-map next week for 2D physics.

EDIT: In the meantime, I've created a sticky thread here with the items about to go into the public roadmap: https://forum.unity3d.com/threads/2d-physics-roadmap.466628/. Please post roadmap related stuff on that thread though please.

 

> if it would allow "local space simulation" in 2D
I'd see this as a perfect use-case so yes, absolutely. For 2D, having a local arcade with lots of little 2D games in progress would be a nice thought experiment. You could manually simulate those as the player reached each one. Lots of other scenarios. Moving between worlds would/should be as simple as assigning a component to another world instance with obvious helpers to help move everything on a GameObject across. Just positioning would need to be handled by you but everything else would be automagic.

A world instance should not have a large memory footprint either so spinning them up should not be a problem but that depends on how we'd expose physics worlds.

One idea I thought about was modifying Box2D (even more) so that we actually had a single world with multiple "spaces" which really means multiple broadphases. Spinning up a world means spinning up a broadphase tree. With clever handling of bodies and fixtures, this would mean a very low latency on moving between worlds and drastically reduce the overhead. It would also make performing queries across worlds easier.

So if we end up with multiple worlds (which I'd love to have ASAP) then we'd need to be able to hook-up components to multiple instances. The code isn't the problem, figuring out how to best expose multiple worlds is the tough part for the reasons I state above. Ideas & feedback on that helps make it a reality.

 

There is no garbage produced on all methods on a Rigidbody2D. Also, it would be more polite to start your own thread rather than hijacking this one, thanks. I check the forums several times a day so should see it.

 

The groups do not have to be limited to 32 groups but it's obviously convenient when selecting multiple groups to use. The cost of assigning a group is practically zero as it is quite simply an int assignment; there's no complex structures to update. When the simulation happens, it has a list of allowed groups and only processes stuff assigned to those groups. We could equally allow a list of groups to be specified rather than a bitmask.

We could even have unlimited and named simulation groups and be able to specify those to simulate.

 

There are no downsides. You're calling it instead of Unity during the fixed updates. It's no more complicated than that.

The only thing about doing it yourself is that you're completely responsible for calling it and therefore maintain the physics simulation time.

Note: There's an update on the way that also allows this to be called in the editor outside of play mode too.

 

I think that's wrong. All you're really saying is that you'd choose one set of problems over another. Whether you call this with a fixed time interval or Unity does has zero bearing on frame-independent physics or decoupling input from physics.

If users start applying time-delta per frame then they'll get unpredictable physics that'll less deterministic than a fixed update.

There's no magic bullet.

 

You're running the fixed delta time per frame. If your frame rate is approximately the same as the fixed delta time you have set then this'll be (approximately) the same. You should use a larger delta time constant here that you can change. Also, you should perhaps you call it in the fixed update to give consistent and repeatable results rather than call it per-frame with a time that does not relate to the frame time delta. Depending on your framerate on the device, you'll get different "fast forwards".

Also note, the larger the time delta you pass, the less accurate the simulation will be. You are far better off running the simulation multiple times with a smaller interval to maintain accuracy. Of course, this will affect performance but it all depends on what level of accuracy you want.

 

WIP: 2D/3D physics selecting simulation to run per-fixed-update, per-frame or manually via script: https://gyazo.com/90b59a292958a62a8608d9082b6f4047

https://twitter.com/melvmay/status/877544888254033920

 

Yeah, it's a simple but important change. Personally, I'd like to see the default on new projects for at least 2D to be per-frame to remove the complexity of fixed-update/update decoupling.

 

I cannot give you fixed dates however the R&D behind the scenes has been moving forward for sure with internal prototypes for release in the next 6-12 months. The current development focus for 2D physics is to not continue to build up the generic but fixed native offering i.e. more native components and features (with a few exceptions such as multi-threaded physics) but rather we're exposing what is internally called the "Low Level Physics Primitives API".

You can think of this as a decoupling of physics from GameObjects/Components but much more than this, the LLAPI gives you raw access to 2D physics primitives, exposed using a super light wrapper in C# (it's a direct access to the native object and has no state itself). You'll get access to world instances, bodies, shapes, joints, contacts, callbacks etc. The shapes can be used directly with new thread-safe (for C# job-system) queries so you query them using a specific transform and perform raycast, linecast, overlap (etc) intersection tests on them i.e. no simulation, just primitive transform shapes for multi-threaded queries.

The other method of usage will be creating a world instance (for simulation), adding bodies, adding shapes to bodies, adding joints connecting bodies, performing queries, running the simulation (or running specific aspects like contact discovery only) and hooking into world instance events like pre-solve, post-solve, begin-contact, end-contact etc.

We'll be offering equivalent colliders but external to the editor and open-source. You'll be able to create your own as you'll have all the tools we have. This is the way forward with only minor improvements/features for the native components.

 

Collision reporting is done after the simulation step has completed so this is the state of all objects afterwards. The velocity is always the final solved velocity.

I'm not sure what you're trying to get but the collision report provides you with a Collision2D type and contacts that are ContactPoint2D each of which provides normal/tangent impulse forces applied during the simulation as well as their relative velocities.

If you want to snap the velocity before the simulation is run then yes, running the simulation manually can help you with this because you can grab whatever values you like, run the simulation then look at the values after.

Note: The loop you asked about above is simply ensuring that the simulation is run with a fixed time-update. It's just tracking the game-time and running the simulation a number of times to ensure that it's always as close to game-time as possible. You don't have to do this, you are free to run it in whatever time-step you choose, even per-frame time-delta however performing the simulation with a variable time-step can mean reduced determinism. In many cases for many games however, this doesn't matter so you'd need to determine that for yourself. If you're not dealing with sensitive collision scenarios such as stacked objects, finely-tuned joints or the need to have such games work identically across various devices then you are free to just run the simulation per-frame. Doing this also means you don't need to perform interpolation of bodies as they are always updated per-frame anyway.

Hope this helps.

 

Seems you are getting very confused over stuff. You extracted the code example but the actual help pages shows you where it's run i.e. in a monobehaviour in the update method: https://docs.unity3d.com/ScriptReference/Physics2D.Simulate.html

This is pretty fundamental stuff. Physics systems (of all kinds) provide a more stable simulation if executed in fixed steps. Each frame however is not rendered in fixed steps and takes a variable time so this means that the physics step is out of sync with the frame render. You are free to change the fixed time-interval in the Time Manager settings to be whatever you like. By default they're 50Hz but can be changed to anything.

Assuming you've not already, you should read some of the detail in the physics manual here.

I cannot answer who. I don't know what you mean by where. They are doing it in the situations I already mentioned where the simulation doesn't need to be as accurate or consistent. Running the simulation per-frame means that the simulation is obviously always in-sync with the frame render but that's running the simulation with a variable time-step.

No extra consideration is required at all, it just works out-of-the-box but if you want more control then you are free to take control and perform manual simulation using your own time-step set-up. Many users have asked for this.

You should read the physic manual but yes, as I said above, change the fixed-time step to permanently run at whatever frequency you want or manually run the simulation passing it the time-interval you want to use; both are the same thing.

Here's a post that provides much more info on the fixed or variable time-step:
https://gamedev.stackexchange.com/questions/1589/when-should-i-use-a-fixed-or-variable-time-step

This document in particular is very good: https://gafferongames.com/post/fix_your_timestep/

 

There's a wealth of information on this subject on these forums and in the many tutorials.

Only if you're using Vsync. Beyond that, it's highly variable from frame-to-frame.

I am not sure what you are trying to achieve here though. This post isn't about what the current default fixed time-delta is or might be in a particular beta or what other systems do (I will enquire however as it's the first I've heard of it). I am not involved in controlling what those defaults are and if they don't make sense then I would suggest you post that in the 2018.1 beta forum. If you have any other specific problem or request then I would suggest you do that in the appropriate forum on another post too.

 

I don't understand what you mean. You apply forces to Rigidbodies same as before, it's just that you control "when" the simulation runs as opposed to it automatically being run for you. See here for when fixed update is called: https://docs.unity3d.com/Manual/ExecutionOrder.html

I have already answered this above or have at least tried my best. I gave you links to documents that explain the concept of fixed-update it in detail. Sorry but I am not going to write out a complete description of all that information again here.

I would ask that you take more precise questions to a separate thread.

 

btw, I just looked at it seems the 0.0167 you're seeing is from the project template which is new in 2018.1: https://docs.unity3d.com/2018.1/Documentation/Manual/ProjectTemplates.html

Hope that helps.

 

Me too and it was before my time here. Seems the new templates default to 60hz so it's history now. Unity is undergoing many changes to remove technical debt including having a default of 50hz and not being able to run the simulation per-frame. You can now do that. Also there's a new feature allowing you to run the simulation in fixed-update or per-frame automatically as well as the custom option to execute it when you like in script.

 

A point you're missing though is that 60fps is only when you're using Vsync. Without that you're not going to get that and its variable. Every physics system prefers to use a fixed time-step so running it per-frame is only useful when you can fix the frame-rate on all devices and that isn't realistic. This is why fixed-time exists so you get the same/similar simulation on every device, frame-rate independent. Then there are projects where this doesn't matter so you can use a variable time-step for your physics.

So I think we've abused this thread topic enough.

 

What do you mean by "problem with the frame rate"?

If your fixed update is 60Hz and your frame-rate is fixed at 240Hz (somehow) then it'll call the fixed-update every 4 frame renders. In other cases, the frame-rate will be variable but the physics will always be called in consistent time-steps which is what physics wants.

This is all about decoupling physics from the variable frame-rate. If you don't want that and your frame-rate on all your devices are consistent (or you don't care about variable time-step physics) then simply call:

Code (CSharp):

1. Physics2D.Simulate(Time.deltaTime);

The doc I linked above explains this quite well.

Again, there's no need to use the code above, that's used as an example only and is already done for you when auto-simulation is on.