Search Unity

  1. Unity 2019.2 is now released.
    Dismiss Notice

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

Discussion in '2D' started by MelvMay, Apr 16, 2017.

  1. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,832
    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.
     
    Last edited: Apr 16, 2017
    rigel0101, dees2019 and DMeville like this.
  2. luchong12

    luchong12

    Joined:
    Jul 15, 2013
    Posts:
    3
    This is great news! Its good to hear that more low level physics stuff is going to be exposed. I thought the latest additions (Physics2D.Distance, etc) were cool but its nice to know it wont end there.

    Also, I don't know if this is the right place to ask this but are you planning on adding anything else related to "manual" collision resolution? I think those kinds of helper functions are really helpful for making character controllers and just wanted to know if there was anything else you had in mind.

    Anyways, thanks for the new stuff, I think a lot of people will love the manual simulation feature :)
     
  3. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,832
    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.
     
    Last edited: Apr 17, 2017
  4. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,334
    This looks fantastic but I was wondering if it would allow "local space simulation" in 2D and eventually have 3D parity? It's one of those issues that's just a pain (character is in car, must just pretend car is world for gameplay purposes) or on platforms and so on...

    How does this work / fit in with the platform or car scenario where multiple rigidbodies will move in and out of that space during gameplay? Also expect hundreds of such spaces (one for each platform that moves etc)
     
    DMeville likes this.
  5. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,832
    > 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.
     
    DMeville likes this.
  6. RockyWallbanger

    RockyWallbanger

    Joined:
    Mar 16, 2014
    Posts:
    78
    I don't care for utilizing Unity's existing layer system for simulating a time step. In my particular case, I found that I needed to create several "sub-layers" depending on the current state my game is in. I'm phasing out as much of my layer system as possible with contact filters because I find the layer system so messy. I really like the idea of simulating selected bodies and to a lesser extent, simulation groups. I think having both in the API would be extremely useful.

    Furthermore, I'd love to be able to individually simulate only a single rigidbody. I'm sure I could manage it fairly easily with Physics2D.Simulate(time, Rigidbody2D[] bodies), but a call to Rigidbody2D.Simulate(time) would be more intuitive and useful to me.

    A sample use case for that feature would be for dragging an object around a scene and placing it in it's "rest" position without it effecting anything in the scene. Currently I've been unable to unilaterally solve this for my game and have had to settle for a game mechanic than what I'd prefer. I believe controlling the simulation at the rigidbody level is exactly what I'm looking for.
     
    MelvMay likes this.
  7. Leuthil

    Leuthil

    Joined:
    Jul 26, 2013
    Posts:
    94
    In regards to multiple worlds:
    I feel as though introducing the concept of multiple physics worlds into the UI of the Editor or exposing this in some way just seems like a complication that will make everything harder for 99% of the users. However for the 1% of users who may actually want to use multiple worlds, I feel like they will be doing this all in code anyway. The only hard part perhaps would be that if there was no world indicator in the Editor then debugging may be a bit more challenging, but I'm not sure.

    My point being that this seems like something that can be offered in code only. I don't really have a good suggestion for how this would actually look from an API perspective. It seems to me like Physics2D should really become instanced instead of static, since all the functions Physics2D has would really be on a per-world basis. In that sense, would it be possible to keep Physics2D.X calling only the default first physics world, but instantiating a new world would have all those same function calls. For example perhaps:
    Code (CSharp):
    1. // Run on default physics World
    2. Physics2D.Raycast();
    3. // Run on new physics World
    4. Physics2DWorld world = Physics2D.CreateWorld();
    5. world.Raycast();
    This still presents the same problems you mentioned in regards to adding components to specific physics Worlds, which would indeed be messy. The option to set which World is the current context is not a bad idea (in which case my code above wouldn't make sense). It would definitely work and would probably be more efficient than setting the world for every GameObject created. I would much prefer having either of these options over having nothing at all, but out of all the options listed the context switching seems like it would be the most performant.
     
    MelvMay likes this.
  8. varloc

    varloc

    Joined:
    May 17, 2014
    Posts:
    1
    This has helped me in many ways and benefited me in producing my work in great ways and i would just like to say many thanks for having brought this to light. I dont require anything additional just for my issue to be solved.

    Whenever i call a method from a rigidbody2d, it gives me 1 kb worth of garbage. Is this how it is supposed to be or is there some sort of glitch which can be overcome?


    Upd: I'm sorry for offtopic :(
     

    Attached Files:

    Last edited: Apr 26, 2017
  9. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,832
    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.
     
  10. shcipwa

    shcipwa

    Joined:
    Jan 18, 2014
    Posts:
    55
    Partial simulation being my main focus from the above, being able to provide a list of rigidbodies would be our preferable solution. I feel that as partial simulation is a fairly advanced topic, the added complexity of maintaining your own lists isn't really an issue and would allow more advanced uses like spacial partitioning over very large areas without being constrained to 32 cells.

    I am on the 3d side of the fence right now but figure the API choices would be fairly similar. My use case would be client side prediction of vehicles (players use character controllers so are already fine).

    The number of vehicle rigid bodies is fairly low in the context of the entire 12km x 12km world, and in a localized area would rarely be interacting with more that a few other vehicles. When a correction is detected, the client side re-extrapolation could be easily isolated to a very small number of rigid bodies around the correcting vehicle for good results.

    Static predefined groups like the screenshot in your tweet would be fine, we could just run all vehicles on one layer, however we would end up doing more CPU work than needed when a correction happens. Alternatively we could constantly hop rigidbodies between groups but I don't really have a gauge on the perf impact of this given your solution.

    Right now all we have is streaming positions of physics run on the server. Any form of partial simulation would be something we can work with.
     
  11. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,832
    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.
     
  12. shcipwa

    shcipwa

    Joined:
    Jan 18, 2014
    Posts:
    55
    In that case I would be happy with any of the suggested solutions, fingers crossed to see it in 3D physics land at some point.

    Appreciate your efforts!
     
    DMeville likes this.
  13. jjfernandez

    jjfernandez

    Joined:
    Apr 8, 2017
    Posts:
    2
    Hi MelvMay,

    Can you tell us about downsides of calling Physics2D.Simulate manually?
    Like calling Animator.Update is breaking the multi-threading. Is something like that happens in physics case?
     
  14. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,832
    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.
     
    Last edited: Jun 4, 2017
  15. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,334
    It's just a shame this wasn't default way back when. The idea of fixed update just adds complexity and creates endless bugs for people new to Unity, most who struggled with input being out of sync and not knowing where or when to add forces.
     
  16. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,832
    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.
     
  17. donamin1

    donamin1

    Joined:
    Apr 4, 2013
    Posts:
    20
    Kinda Solved: I had to turn VSync off :). It still needs a lot of implementation before it's completed. But now I have 4x speed compared to before. And I'm not sure if it can cause any bugs in physical computations or not (because increasing timeScale results in a lot of bugs)

    Hi

    Thank you for adding this manual simulation feature. It's great! However I have one question.
    I'm using this feature for implementing a simulation framework as a teaching material for a game-related course in our university. So a very important feature for us would be to run fast simulation. So I implementing an infinite loop for simulating the world which is roughly as follows:

    Code (CSharp):
    1. IEnumerator MasterUpdate()
    2. {
    3.     while (true)
    4.     {
    5.         Physics2D.Simulate(Time.fixedDeltaTime);
    6.         yield return null;
    7.     }
    8. }
    As you can see, it's a simple loop which will never end. I start this coroutine at the Start() event.
    So here's my question:
    I expect from this loop to fast forward the simulation because I'm not letting any pause to happen between simulations, but when I run this code, the game is running in the normal speed. Why is this happening? And how can I make this do some fast forward simulation?

    Thanks in advance
    Amin
     
    Last edited: Jun 21, 2017
  18. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,832
    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.
     
  19. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,832
  20. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,334
    That looks nice! could you elaborate a little bit on the behaviour of what each does?
     
  21. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,832
    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.
     
  22. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,334
    Makes perfect sense to me, thanks!
     
  23. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    147
    This is truly great stuff. It does make synchronization of procedural stuff with physics stuff much much cleaner, and without the need for interpolation (and the associated error, cpu cost and latency). And it seems pretty stable in the new 2017.1.0f1.

    I have noticed that when using Physics2D.autoSimulation = false and Physics2D.Simulate(myDeltaTime), you still need to be sure to set Time.fixedDeltaTime to something reasonable during init (say, target framerate, or even faster). - I accidentally set it to a large value, and that caused lag with spring joints that were attached to a kinematic rigidbody that in turn was moved by MovePosition().

    Anyway, as long as you remember to set Time.fixedDeltaTime and don't let myDeltaTime fluctuate wildly, this works really really good. Good show, Melv.
     
  24. donamin1

    donamin1

    Joined:
    Apr 4, 2013
    Posts:
    20
    Hi Guys

    I'm having a serious problem with this new feature. It's a complicated problem so I hope I can explain it to you good enough.
    I'm trying to implement MCTS algorithm which makes fast simulations for each possible action to see which action is the best for the agent.
    This is the code of the main MCTS loop I'm working on:

    Code (CSharp):
    1. public void mctsSearch(WorldState rootState, int numIterations)
    2. {
    3.     for(int i = 0; i < numIterations; i++)
    4.     {
    5.         rootState.Load(); //Reset the world state to the initial state of our search
    6.         MCTS_TreeNode selected = treePolicy(); //Updates the world based on previous data
    7.         float reward = selected.rollOut(); //Updates the world using a random walk
    8.         backUp(selected, reward); //Updates the information we have about the world & actions
    9.     }
    10. }
    This code suspends all other processes until the loop is finished (I know that suspending is bad in game development but this is an academic project so we're ok with this).
    in treePolicy & rollOut function, I manually call update function for all objects in the scene and after that call Physics.Simulate. So theoretically it should work.
    But it doesn't! It seems that all simulations are kinda getting to the same result (same set of collisions & events). So I guess the problem is that rootState.Load() is not working correctly.
    But rootState.Load() is doing a simple thing. It just rearranges all objects in the scene to the same position & rotation that I stored earlier before initiating the search. But maybe I need to call a forceUpdate for the engine to catch up before I call treePolicy? I don't know.
     
  25. deemen

    deemen

    Joined:
    Dec 29, 2013
    Posts:
    17
    We're part of a team that essentially had to divorce ourselves from Unity Physics2D in order to get our networking prediction engine to work. The change in 2017.1 is a step in the right direction, but having partial simulation / multiple worlds is essentially to get this working for prediction. When playing locally, we have a listen server that must maintain two physics worlds (server and predicted), so the separation is important.

    Any update on the timeline for these features to be in production?
     
  26. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,832
    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.
     
    Leuthil and GarthSmith like this.
  27. deemen

    deemen

    Joined:
    Dec 29, 2013
    Posts:
    17
    This sounds great! Thanks for opening up the API. Looking forward to it.

    Unfortunately for us it means we won't be able to use it for the current project, but surely for the next one.

    Cheers!
     
  28. GarthSmith

    GarthSmith

    Joined:
    Apr 26, 2012
    Posts:
    1,240
    This is great! Thanks for the updates!
     
  29. Cakeszy

    Cakeszy

    Joined:
    Jun 7, 2017
    Posts:
    4
    Hi deeman,

    I am also working on a project that requires physics to be networked. I specifically need simulation groups to push forward the simulation of specific objects for client prediction based on an authoritative server update. I am wondering what physics engine you switched to to complete your project? I am at a standstill with my project with nowhere to go until I can manually run the physics simulation for separate game objects.

    Any help would be greatly appreciated!
     
  30. deemen

    deemen

    Joined:
    Dec 29, 2013
    Posts:
    17
    We wrote a custom engine based on raycasting. Our game has platforming physics so it turned out okay. It's nowhere near as robust as Unity's built-in physics but it works for our purposes. I suppose in theory you could use something like Box2DX but we never made the leap.
     
  31. Cakeszy

    Cakeszy

    Joined:
    Jun 7, 2017
    Posts:
    4
    I appreciate it deeman, thanks. I'll look into it
     
  32. Deeeds

    Deeeds

    Joined:
    Mar 15, 2018
    Posts:
    739
    1. Code (CSharp):
      1. timer += Time.deltaTime;
      2.        while (timer >= Time.fixedDeltaTime)
      3.         {
      4.             timer -= Time.fixedDeltaTime;
      5.             Physics2D.Simulate(Time.fixedDeltaTime);
      6.         }
      I'm struggling to understand what this does, and how it works, probably because i don't understand what FixedUpdate is good at, and bad at.

      But mostly because I don't see where I can add forces and other things I'd usually do in fixedUpdate.
     
  33. Deeeds

    Deeeds

    Joined:
    Mar 15, 2018
    Posts:
    739
    When getting the angularVelocity of an object during OnCollisionEnter2D, it's not always showing the value it has before the collision, or even at the collision. Sometimes it's (seemingly) reporting the value it would have immediately after the collision.

    Using a variable in Update() to store the most recent angularVelocity (and then using this) overcomes this problem.

    Is this something any of the above mentioned stuff could help with?
     
  34. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,832
    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.
     
    Deeeds likes this.
  35. Deeeds

    Deeeds

    Joined:
    Mar 15, 2018
    Posts:
    739

    "The loop you asked about above is simply ensuring that the simulation is run with a fixed time-update."

    Where is this run? ie. I don't see a simulate(){ put my code in here } callback type space where I can add forces or do other things I'd want to do during a fixedUpdate.

    "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."

    What is "game-time", and what's wrong with FixedUpdate() that would make this kind of thing necessary?

    "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."

    Who, where and why are folks running a variable time-step for physics? How? What for?

    What do you mean by "reduced determinism"?

    "need to have such games work identically across various devices then you are free to just run the simulation per-frame."

    How/why is per frame physics simulation bad?

    If it is bad, why not simply double the physics simulation to 120hz, or quadruple it to 240hz?

    Or why not have it run slightly out of step with the game loop "tick" and its display refresh?

    It seems, from all this, that there must be something fundamentally wrong with how Unity does physics updates if all this consideration is required.

    I'm coming from a Chipmunk2D environment, where I was running the simulation at 240hz, and getting exactly what I wanted. Is there a simple way to replicate that with Unity's (your) Box2D implementation?
     
  36. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,832
    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/
     
    Last edited: Apr 13, 2018
  37. Deeeds

    Deeeds

    Joined:
    Mar 15, 2018
    Posts:
    739
    Part of the problem might be that I have not extracted a code example, and know nothing of where that code example is, or what it's about. I only read this blog post and tried to understand what was going on in the code examples in it.
     
  38. Deeeds

    Deeeds

    Joined:
    Mar 15, 2018
    Posts:
    739
    Yes, fundamental stuff. Agreed, so it should be easily clarified and explained as to how and why Unity does it differently from others, and how to best utilise these differences and approaches.
    This is only true if you're talking about the rendering to the buffer. The rendering to the screen IS done, in most systems, on a very accurate rate, based on the hardware, and the physics systems can then be aligned to that, with that expectation. In newer game engine game loops the expectation seems to almost always be that they should run and act in accordance with this display refresh, and use delta time (only and mostly) to adapt to dropped frames.

    There is, in engines rigged up to loop in this manner, no real need for a division into two update loops on the basis of different adherence to timing because the game loop is rigid enough to be relied upon.

    CADisplayLink, on iOS, for example, runs the loop timings and awareness of SceneKit, SpriteKit, Core Animation and even UIKit Dynamics.

    I hate to be an infantile corrector, but the Unity I'm using (beta13 of 2018.1) has (by default) the fixed time step set to the 0.0167 you might expect if it was attempting to match the 60fps of a game loop running at 60fps. It's not the 0.02 I see referenced in other places.

    I have absolutely no idea why anyone would set a fixed update to run at 50fps when the universal standard for most everything has been 60fps for at least a decade. That deliberate disharmony makes little to no sense, to me.
     
  39. Deeeds

    Deeeds

    Joined:
    Mar 15, 2018
    Posts:
    739
    here's a screen shot of the default time settings in the latest beta of Unity:

    Screen Shot 2018-04-13 at 10.23.31 pm.png
     
  40. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,832
    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.
     
    Last edited: Apr 13, 2018
  41. Deeeds

    Deeeds

    Joined:
    Mar 15, 2018
    Posts:
    739
    "There's a wealth of information on this subject on these forums and in the many tutorials."

    None of which is easy to find, or digest, as it's a mission to wade through it and ascertain the quality of each bit of information until it's been read, digested and tested and contrasted with experience...

    Again, considering how fundamental this stuff is, the documentation should cover this in glory, and make it easy to learn/know about this engine without needing to go through tutorials (the worst way to find anything as it dates fast and takes far too much time for users) or wading through forums (wherein the quality of sources and their legitimacy are often unknowable).

    If it's so fundamental, why isn't there simple, elegant, clear explanations in the documentation?

    As to my question here... it's two fold, and simple:

    Where do I put the applications of forces within a manual simulation?

    What's the benefits of manual simulation, and how is this overcoming innate issues in the way Unity currently handles physics?
     
  42. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,832
    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.
     
    Last edited: Apr 13, 2018
  43. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,832
  44. Deeeds

    Deeeds

    Joined:
    Mar 15, 2018
    Posts:
    739
    Let me try again... we seem to be meandering from the point I'm making and the question(s) I'm asking about the original post that is this thread.

    In it, you have a bunch of code, that's supposed to simulate how AutoSimulate works...


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


    I’m missing some basic logic.



    And it could just be me that’s missing this.



    The only reason this simulation will ever get called is if the update() callbacks from Unity are taking longer than they should, and some time has passed between them that’s longer than it should be. Assuming that the Fixed Update and Update are operating at the same frequency.



    However, what’s to say that this update, in which there’s the hope that a manual simulation will occur, is going to get called whilst the rest of the game is so busy that some update hasn’t finished and is stalling the engine?



    And why is FixedUpdate() not getting a chance to get called (and therefore running/initiating the simulation) even if the update loops are stymied and congested?
     
  45. Deeeds

    Deeeds

    Joined:
    Mar 15, 2018
    Posts:
    739
    There are two problems with me discussing this stuff:

    1. I'm a designer
    2. 2018.1 betas (from b11 through b13) are my first serious exposure to Unity.

    But I'm still VERY curious about why FixedUpdate was at 50fps and frame-rates (the world over) default to 60fps... up until these betas. That's peculiar.
     
  46. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,832
    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.
     
    Last edited: Apr 13, 2018
    Deeeds likes this.
  47. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,832
    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.
     
    Deeeds likes this.
  48. Deeeds

    Deeeds

    Joined:
    Mar 15, 2018
    Posts:
    739
    Please, @MelvMay, humour me for one more frame...

    I think there's an error in this, in that it won't call the simulation unless there's a problem with the frame rate:

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

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,832
    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.
     
    Last edited: Apr 13, 2018
    dees2019 likes this.
  50. Deeeds

    Deeeds

    Joined:
    Mar 15, 2018
    Posts:
    739
    Imagine the situation you describe, and the reason for your sample code, that you're replicating how autosimulation works so that you can show how the manual simulation works.

    Also imagine that you're running the game at 60fps and that the fixed step is at 60fps, just as would be the most common, most normal way to do this.

    There is this line:

    timer += Time.deltaTime


    This means
    timer
    = the amount of time the last frame took. From my understanding, this is going to be 0.0166666

    The conditional that calls the simulation, manually, is in a while loop, that requires timer to be larger than the fixed time step before the simulation will be invoked.

    If nothing goes wrong with the frame rate, that's never going to happen.
     
    dees2019 likes this.