Search Unity

Calling the physics simulation from C#

Discussion in 'Physics Previews' started by yant, Dec 6, 2016.

  1. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    290
    I don't exactly follow the q. Clearly, the physics simulation is multi-threaded. The understanding that it may happen in the thread you've started it from is not exactly right. Now, certain coordination of the worker threads has to be done from the main one, but this won't be fixed automatically by just allowing to call Physics.Simulate from another thread.
     
  2. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    290
    There are a couple of ideas here.

    * The main driver for this feature was apparently... nested prefabs. The preview window is a separate scene where we do raycasting against only the prefab that's being previewed (in isolation from the other objects)
    * Now, one could think of many cases where having a separate physics scene could help: prediction, computing trajectories, lower-frequency sim, networking.
    * Yes, currently Physics.Simulate would write the poses from the physics engine to Unity transforms every call, which may be wasteful. We have a plan to address that by exposing an enum to control what stages of the simulation pipeline to run. Could use that to turn off that costly readback for example.

    "Are there any optimisation opportunities with multi scene physics, or is it still better to have one scene in that respect, so long as they're on different layers?"

    I think that would depend on the number of objects you have. Clearly, separating objects into separate scenes (by layers) would give you natural isolation, supposedly better broadphase perf etc. Filtering should be faster too (fewer pairs to check).
     
    GarthSmith likes this.
  3. Stanchion

    Stanchion

    Joined:
    Sep 30, 2014
    Posts:
    258
    @yant In my proof of concept of client side prediction for server auth rigidbody players (see here) I have each client have a separate scene just for their player where the only rigidbody present in the scene is the player's so that other rigidbodies in the game won't be affected. However since physics scenes don't interact with each other I have each nearby object with collision have a "mirror" in the player scene so the player will be able to move on terrain, run into other players, etc. Does this seems reasonable or do you see a better approach? Is it possible to have physics scenes interact with each other in the future?
     
    Jick87 likes this.
  4. TheOtherMonarch

    TheOtherMonarch

    Joined:
    Jul 28, 2012
    Posts:
    83
    @Stanchion not sure why you would need multiple physics scenes on the server that sounds strange the server should have one master physics scene on the clients physics should just be client side prediction.

    Note that client side prediction does not even have to be physics based. The clients then get new positions from the server and do some type of blended update. In many cases the clients can be kinematics and be updated from the server physics. It depends on how fast moving your objects are.

    Personally I used the blended dead reckoning described in chapter 18 of Game engine Gems 2.
    Oddly true client side prediction is more important for kinematic character controllers which are unpredictable. Like I said personally I would not run bouncy physics (Unity Physx) on the clients. Unless it was just a unsynced graphics effect.
     
    Last edited: Oct 20, 2018
  5. Stanchion

    Stanchion

    Joined:
    Sep 30, 2014
    Posts:
    258
    @TheOtherMonarch In my proof of concept there is just one scene on the server, the special setup is only on clients.

    Client side prediction requires the simulation being done on the server to run on the client, otherwise you are just smoothing or "blending" the results. That means you will not see immediate reaction to your input on the client. World of Tanks has no client side prediction (so they do smoothing and have servers in many regions to minimize latency) while Rocket League does have client side prediction. They are both very successful games so there's nothing wrong with choosing no prediction for rigidbodies but it can cause issues in fast paced games. That is why I am figuring out how to make this work with Unity physics now that you can fast forward simulation of a single rigidbody after you receive a correction from the server.
     
  6. cemnahit

    cemnahit

    Joined:
    Dec 26, 2012
    Posts:
    38
    Hi, did you ever had the chance to share the billards demo?
     
  7. Stanchion

    Stanchion

    Joined:
    Sep 30, 2014
    Posts:
    258
  8. Stanchion

    Stanchion

    Joined:
    Sep 30, 2014
    Posts:
    258
    Hopefully we get an update this year :)
     
    recon0303 and DMeville like this.
  9. Leuthil

    Leuthil

    Joined:
    Jul 26, 2013
    Posts:
    94
    Multiple physics scenes on the server could be useful for implementing lag compensation. It is probably possible to do it without multiple physics scenes, but it could get really complicated.
     
  10. DerDicke

    DerDicke

    Joined:
    Jun 30, 2015
    Posts:
    176
    Found this thread by coincidence and didn't read all of it, but a big THANK YOU for giving us the opportunity to handle PhysX simulation steps by ourselves.

    For all the poor souls like me messing with PhysX and rendering synchronization for weeks and still weren't able to avoid microstuttering when using Rigidbody based Player Controllers, maybe the answer is this little script.
    It just simulates PhysX in a variable timestep, which is absolutely no problem at all (despite Nvidias documentation). Implemented the same principle 10 years ago in a commercial game and it worked like a charm. Just avoid updating anything in FixedUpdate(), for all things use Update().

    Code (CSharp):
    1.  
    2. public class PhysicsUpdate : MonoBehaviour
    3. {
    4.     void Start()
    5.    {
    6.         Physics.autoSimulation = false;
    7.    }
    8.  
    9.     void Update()
    10.     {
    11.         if (Physics.autoSimulation)
    12.             return; // do nothing if the automatic simulation is enabled
    13.  
    14.         float f = Time.deltaTime / Time.fixedDeltaTime;
    15.         int rounds = Mathf.CeilToInt(f);
    16.         if (rounds == 0) return;
    17.         float delay = Time.deltaTime / rounds;
    18.  
    19.         for (int i=0; i< rounds; i++)
    20.         {
    21.             Physics.Simulate(delay);
    22.         }
    23.  
    24.  
    25.         // Here you can access the transforms state right after the simulation, if needed
    26.     }
    27.  
    28.  
    29. }
    30.  
     
  11. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,155
    UE4 has always been simulating physics by default at frame update speed (using same PhysX). They have substepping option but even that is made so that substeps total time is matched to the frame update interval (which is what your script does here).
     
    Last edited: Feb 4, 2019
  12. DerDicke

    DerDicke

    Joined:
    Jun 30, 2015
    Posts:
    176
    Good to know.
    Another big time reason to make actual games with your engine. Microstuttering is not noticeable in 5 minute functionality sandboxed tests. You have to work on a real world project.
    Hopefully some former GameDevs start working at Unity to make them believe ;-).
     
  13. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,460
    Do be careful of this approach though, you'll miss things like attacks and so on. By using a fixed timestep, you can still guarantee things that should be happening regardless of temporal nature.

    So for a lot of games being pure delta works well, but for games where timing is of the essence like dark souls or street fighter, or games that need to run from 10fps to whatever, these benefit from fixed timesteps.
     
  14. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,155
    That approach is doing substepping tho, so it's not as bad as simply doing one physics update per frame. With shown subtepping code your physics simulation time will vary but will stay under fixed deltatime (meaning you'd get at least as many physics steps as with fixed timestepping, sometimes 1 more).
     
    hippocoder likes this.
  15. DerDicke

    DerDicke

    Joined:
    Jun 30, 2015
    Posts:
    176
    The ability to read code cannot be overstated ;-).
     
    hippocoder likes this.
  16. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,460
    I'm quite surprised that Interpolation didn't solve it and made it necessary to run in sync with update.
     
  17. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,155
    If interpolation works properly, it would be exactly as fluid as simulating with variable timesteps synced to the update rate. There has been some issues in past for Unity's interpolation but afaik it should work on current versions.

    One thing that does change is the response time as when you run the last physics simulation step to match the frame update, it's in perfect sync and there's no wait time from simulation, hence no additional delay. If you do interpolation, you see state that's in the past and it will not be quite as responsive to your input. If you do extrapolation, you see where the object should be at that given time but since extrapolation is basically projection to estimated future state of the simulation, it can be also be wrong and make your visuals glitch.
     
  18. DerDicke

    DerDicke

    Joined:
    Jun 30, 2015
    Posts:
    176
    So when do OnTriggerXXX(), OnCollisionXXX() be called when simulating manually?
    I would assume they will be called when the next fetchResults() call to PhysX happens. Is this done at the beginning of the next frame?
    Also simulate() in Physx is meant to be paired with fetchResults(), so in vanilla PhysX calling simulate() two times in a row probably does nothing (for the second call).
    But in my tests my script seems to work, so I assume a call to Unity.Simulate() simulates a whole PhysX.simulate()/PhysX.fetchResults() cycle. This would mean that OnTriggerXXX() is called while my script calls Unity.Simulate().

    Update:
    Debugging seems to confirm that Unity is doing a full PhysX.simulate()/PhysX.fetchResults() cycle every time Unity.Simulate() is called... ok, this is nice to avoid Unity microstuttering, but eliminates the ability for doing physics in parallel e.g. while rendering....
    So you pay with performance to fix microstuttering.

    Honestly it would be nice if we could choose between two Physics modes, first one would be what we have right now, lets call it 'Prefer Physics Simulation' where you have const simulation timesteps giving you a deterministic simulation, but lots of stuttering because Physics based movement is not in sync with rendering and movement updates using Time.deltaTime.
    Second would be 'For Games' where Unity does what UE (and my script) do, but would simulate in parallel and not block the main task like my script does, e.g simulate next frame in parallel while rendering. Would give non-deterministic simulation, but no stuttering.

    Any thoughts?

    EDIT: made my point more clear
     
    Last edited: Jan 11, 2019
  19. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,155
    This should be right / wouldn't make sense for unity to defer the events to later stage as it would just add overhead and delay for no good reason.

    This isn't how it works. Unity is always running physics simulate x times on main thread at the beginning of the main loop if you use the automatic approach. Only difference really here when you run the simulation yourself on Update() is the order of things might run (you can still force your physics stepping script runs first). To see what happens normally on execution order, you can check the chart on the bottom of this page:
    https://docs.unity3d.com/Manual/ExecutionOrder.html
     
    Last edited: Feb 4, 2019
  20. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    290
    All callbacks are called from within Physics.Simulate is called, either automatically by Unity, or manually from your script, it doesn't matter. Physics.Simulate aggregates everything. That is both good and bad, of course. Melvyn and myself were thinking to ship a variant of Physics.Simulate that allows more discreet control over what it does under the hood. A common idea would be to skip read-back from PhysX, in case you're simulating forward and interested in the final poses only. In general, the way for the current, GameObject-based physics would be to evolve it to a less black-boxy state, while not breaking everything that worked for a decade before. Some particular things will be broken of course, the ones that originate directly from the early days and are no longer in any close touch with the new reality, however a lot of concepts should remain. Less black-boxy would mean more manual, and granular control over everything. All simulation stages exposed as job handles if applicable. Would allow to chain contact modifications for instance.
     
  21. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    290
    As to sub-steps -- it's probably been discussed elsewhere. The core of the problem is determinism. Once you start feeding physx variable deltas, you're no longer getting the same result with each run, especially when non-linear processes are involved (ie joints, heavy contact responses). One could argue the error is usually small, but in countless projects I've seen over the years the small errors tend to accumulate over a few frames and then make a huge difference. It's a difference between hitting a target and missing. It's what decides win/loss. Physics simulation is not a stable function if you may. A perpendicular problem is that some algorithms may not converge that well being provided inconsistent deltas.
     
  22. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,155
    Yes please :D (but my opinion on this was probably obvious from previous discussions)

    I forgot to mention this as most people making single player or VR games don't really care for absolute determinism. In my experience as soon as you make even tiniest change here, all determinism is off but that's also pretty obvious if you know how physics simulation works. Even if you have last digit on single position vectors value off by one, you can have a collision that will bounce into totally different direction (I've done determinism tests on UE4's physx integration when I implement fixed timestepping there myself).

    There's one thing to note about PhysX and determinism tho: I've never managed to make deterministic resimulation using PhysX even on same computer unless I literally initialize everything again from scratch to the same point. If you just manually set PhysX rigidbodies values to same transforms and velocities they were in past between simulated physics scenes steps, determinism will be off and it will not simulate 100% same anymore (disclaimer: I've not verified this to happen on Unity but I'd expect it to apply here too as I tracked the issue before to be on PhysX side of things).

    When I debugged this through PhysX sources, I came to conclusion that PhysX's internal getters and setters do some floating point math along the way which can at least give those one last digit rounding errors as floating point math is being done before you actually get or set anything on PhysX for transforms for example. Additionally I suspect that there's some internal caching (inside PhysX) that also may affect this but I didn't really dig that deeply into that to know for sure.
     
    hippocoder likes this.
  23. DerDicke

    DerDicke

    Joined:
    Jun 30, 2015
    Posts:
    176
    Don't think determinism matters. I mean, no game relies on a physics engine if determinism is needed. Physics is used for eye candy and 'look real' in games.
    But Unity is infamous for its micro stuttering. I mean, read the forums, watch some youtube statements and so on. Many people think Unity is a bad Engine because it cannot get rid of its stuttering. People usually think Unity cannot maintain a stable framerate, but the truth is missing synchronization between PhysX and the rest of the engine.

    On the other side we have UE, most famous for (high quality) shooter like games. And they use a variable framerate for PhysX in their engine (as rizu stated, I don't know this).

    And if it would be possible to switch from simulation mode to game mode... Best of both worlds ;-).
     
  24. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,155
    Properly implemented interpolation is still perfectly smooth, it doesn't stutter.

    Unity has it's issues on stuttering, it can boil down to many things that are up to devs to fix but some of the core issues are also on Unity's engine side, see this post here: https://forum.unity.com/threads/time-deltatime-not-constant-vsync-camerafollow-and-jitter.430339/ In this kind of case, you can still work around the issue by not trusting the deltatime unity reports to you and figuring out what is the actual true deltatime you should use but this isn't going to be trivial.
     
    Last edited: Jan 11, 2019
    hippocoder likes this.
  25. DerDicke

    DerDicke

    Joined:
    Jun 30, 2015
    Posts:
    176
    Nope.
    Implement a rigid body based character controller without stuttering in a real world scenario and we can talk. The core issue is always the same. Missing synchronization between Time.fixedDeltaTme and Time.deltaTime.

    The common workaround is to make all relevant movement in FixedUpdate() or Update(), but not both. Relevant movement is usually at least the camera. But both approached have issues.
    If you create a character updating in Update(), to sync with the rest of the game, you'll get jittering movement when running into things.
    If you use FixedUpdate() you'll have stuttering because rendering frame rate and Physics frame rate are not syced. It doesn't happen when no Physics are involved.
    All of this can be avoided when scaling Physics framerate. You don't even need FixedUpdate() anymore. Things just run smooth.

    Non-smoothed Time.deltaTime has nothing to do with it, but if you ask me, could be a feature. Hell, even my little engine some 10 years ago had that.
     
    Last edited: Jan 12, 2019
  26. DerDicke

    DerDicke

    Joined:
    Jun 30, 2015
    Posts:
    176
    Ah here, re-discovered this article which explains the problem in detail:
    http://www.kinematicsoup.com/news/2016/8/9/rrypp5tkubynjwxhxjzd42s3o034o8

    InDaFace Video of the issue:


    Still thinking that offering a scaleable Physics framerate that syncs with rendering would satisfy the 95% of clients, who don't implement their determinism dependent of a fixed update time but like to have a smooth framerate, would be an improvement for Unity.
     
  27. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,155
    I'd rather not as it's actually really bad way to implement character controller, I'd almost always advice against doing RB physics based char controller unless there's some really pressing reason to do so (like heavily physics based gameplay with lots of direct physics interactions).

    But what I've been trying to tell now on multiple posts here that both interpolation and syncing to update both can provide equally smooth movement as they both are literally synced to the frame update. You can't have other being smoother if you use the same target time for the final physics state. If you still target the same delta and you get more stuttering on either approach, you do something very wrong.

    Note however that I'm NOT saying that built-in interpolation and your method would necessarily provide equally smooth motion because I don't actually know the interpolation code inside Unity (they could use different smoothed delta time instead for their main target and like I said, there are issues on how Unity calculates the delta times) but I can guarantee you that if you do the interpolation using same delta target as with your direct physics simulate, it will give equally smooth motion.

    I don't think you quite understand what's happening on the interpolation math here. It's literally only putting display in sync with two past physics states in a way that you get values between them which would point to the exact location on previous frame (so it's technically rendering it one frame late but in perfect sync, feeling butter smooth if implemented properly).

    This is exactly what rigidbody interpolation is used for in game engines.
     
    Last edited: Feb 4, 2019
  28. DerDicke

    DerDicke

    Joined:
    Jun 30, 2015
    Posts:
    176
    Let me explain what the guy does in the video.
    - He is using a RB based character controller
    - Because he updates Physics at 50 FPS and his framerate is most probably much higher, we get stuttering. This is because Physics and game framerate is not in sync.
    - He temporarily fixes it by setting an insanely high Physics framerate, something you cannot do in a real world game.
    - Then he tries a second approach. He reduces the game frame rate to the Physics framerate. This reduces the stutter for this *demo* scenario, because the *demo* will always be able to render at 60 FPS.

    All the time he is talking about a temporary fix and a workaround. He does this because he thinks as a game developer. He *knows* he cannot ensure his game will always be able to run at 60 FPS. He knows that some people, some *clients* will get angry if he forces his game to run at 60 FPS *only* because the Physics engine is buggy and freaks out.
    This is the view of a *game developer* using Unity. We don't want determinism from a physics engine. We want smooth framerates. Don't think for us. Let us build determinism where we need it.

    I'm so sure if Unity would make a game, they would instantly understand this. Because when people start throwing things at you because your engine doesn't run smoothly you figure out very fast that mathematical precision means nothing in game development.

    And of course Time.deltaTime is the frametime of the previous frame. What else could it be? It could be an interpolated value over several frames (which is another thing Unity doesn't offer because they never developed a game), but that was it.

    As a side note: I'm earning my money in programming for 20 years. Much of the time in game engine development. So you can be pretty sure I understand the topic I'm writing about (most of the time). On the other hand it is just impolite to call other people idiots and tell them they don't know what they do.
     
    Last edited: Jan 12, 2019
  29. Scott-Michaud

    Scott-Michaud

    Joined:
    May 26, 2015
    Posts:
    14
    I'm guessing you already know this -- but you definitely can increase the physics framerate in real-world games. The thing is that you need to spec it out in your prototypes and account for that assumption going forward.

    If your physics are mostly set up for cosmetic effects and your game logic is done by hand, either for non-physical ("arcade") feel, performance optimization, or whatever, then you can spec out a longer physics timestep save the physics engine from doing all of these big calculations. Great.

    If your game heavily relies upon physics, such as a destruction derby game with car parts that fly off, a Hitman-style game where you need to move ragdolls, or a game with rigid body physics on the main character, then you should account for more performance in the fixed update. It's no longer cosmetic, so you need to dedicate more processing time to it.

    You need to pay careful attention to what your game needs, and allocate resources appropriately. The more you know about your problem, the better solution you can design for it. Unity cannot. Unity needs to pay the cost of generalization to account for the many different problems that Unity's engine is used to solve. That always has a cost.
     
  30. zenheads

    zenheads

    Joined:
    Nov 3, 2014
    Posts:
    6
    @yant @MelvMay it would be great if the billiard test scene was available to have a look at. Having an actual prediction implementation would serve as a great reference point for many of us. thanks in advance!
     
  31. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,460
    Nah. For you. Not for me.

    For me it's about consistent gameplay, and being able to network with it while saving myself a *lot* of money. Determinism in Physics is one of the biggest searched terms relating to game physics and to say it's not needed demonstrates that you have become authoritative over your own personal experiences.

    Trust me, you are only right in your own bubble.

    In our case the cosmetic physics are done outside of Physx because it's faster to use ECS to make things bounce, or use Animator jobs to make bits flap and wiggle. Animated physics in real games are rarely done using an actual Physics engine and rely heavily on approximations.

    It's only recently you get indies trying all sorts of un-released cosmetic things with Physics engines because it's easy to do (even though very inefficient to do so).

    A huge amount of Physics code for games is often about correcting the behaviour of the physics simulation, and this is very telling.
     
    IsaiahKelly and deab like this.
  32. TheOtherMonarch

    TheOtherMonarch

    Joined:
    Jul 28, 2012
    Posts:
    83
    Determinism is helpful for any kind of networking. However it is only crucial for lockstep / hybrid networking. Most people should simply not run physics on the clients.

    Cosmetic things like explosions / destructive environments can be done on the clients. Where the frames do not need to sync up. Floating point errors from c# make determinism basically impossible. If you are networking a RTS or fighting game then do not use Unity.

    The users crying about physics interpolation should try interpolation with 333 milliseconds between updates.
     
    Last edited: Jan 16, 2019
    hippocoder likes this.
  33. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,460
    For 333 ms we need to probably just let the client think whatever reality is local to them is the reality, then correct when something eventful happens :D
     
  34. Jean-Fabre

    Jean-Fabre

    Joined:
    Sep 6, 2007
    Posts:
    335
    Hi,

    Any chance to get the Billiard example available for study? I can't find any implementation that would allow one to study how to work with all this.

    Bye,

    Jean
     
    deab, cel and Stanchion like this.
  35. Stanchion

    Stanchion

    Joined:
    Sep 30, 2014
    Posts:
    258
    @yant This would be great
     
    cel and recon0303 like this.
  36. hogwash

    hogwash

    Joined:
    Oct 12, 2012
    Posts:
    115
    Hi @yant is it possible to use RaycastCommand with a PhysicsScene?

    Thanks,
    Tom.
     
  37. hogwash

    hogwash

    Joined:
    Oct 12, 2012
    Posts:
    115
    Anyone looking for a solution until it's properly implemented, here's a blocking version:


    Code (CSharp):
    1.  
    2. public static JobHandle ScheduleRaycastBatch(this PhysicsScene physicsScene, NativeArray<RaycastCommand> commands, NativeArray<RaycastHit> results, int minCommandsPerJob, JobHandle dependsOn = default(JobHandle))
    3. {
    4.    if (physicsScene == Physics.defaultPhysicsScene)
    5.    {
    6.        return RaycastCommand.ScheduleBatch(commands, results, minCommandsPerJob, dependsOn);
    7.    }
    8.    else
    9.    {
    10.        for (int i = 0, imax = commands.Length; i < imax; ++i)
    11.        {
    12.            var command = commands[i];
    13.            RaycastHit hitInfo;
    14.            physicsScene.Raycast(command.from, command.direction, out hitInfo, command.distance, command.layerMask, QueryTriggerInteraction.Collide);
    15.            results[i] = hitInfo;
    16.        }
    17.  
    18.        dependsOn.Complete();
    19.        return new JobHandle();
    20.    }
    21. }
    22.  
     
  38. w0nche0l

    w0nche0l

    Joined:
    Feb 21, 2015
    Posts:
    4
    bumping this thread, @yant it would be great to be able to see that billiards example.
     
  39. DavidSWu

    DavidSWu

    Joined:
    Jun 20, 2016
    Posts:
    121
    Interpolation of physics adds input latency. It may not be much but the time between player actions and response is extremely important in most games.
    Back in the '90s when I built my first engine, I structured things to minimize the time between a player doing something and seeing results on screen.
    When we first got multi-core consoles, so many people went with deep pipelines that were good through throughput but bad for latency. It seemed totally wrong to me.
    I have always preferred using data parallel techniques (i.e. all cores focusing on gettings one task done as quickly as possible) to get latency down over task parallel techniques (i.e. pipelines handing off data from one processor to the next).

    Forgive me, I got carried away and have gone off topic.
     
    Last edited: Apr 4, 2019
  40. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    290
    Please appreciate that billiards example was basically a quick demo to prove the concept. It's not exactly the best piece of engineering, and most likely, not something that would serve as a golden standard of Unity coding.

    Having that said, I uploaded the raw project here, since it's already been shared on Discord and elsewhere: https://drive.google.com/file/d/1g5dBCPsfXApG_k3SqIIBx0z9BpEXSc25/view?usp=sharing

    Anthony.
     
    w0nche0l, GarthSmith and Stanchion like this.
  41. Jean-Fabre

    Jean-Fabre

    Joined:
    Sep 6, 2007
    Posts:
    335
    Hi,

    Thanks! this will greatly help porting this to PlayMaker, much appreciated! don't worry about standard, we just need to see how you use the api to get a feel for it.

    It has few errors, but I'll try to find out what is the new api, It's likely because you did that in an alpha version.

    Bye,

    Jean
     
    Stanchion likes this.
  42. Stanchion

    Stanchion

    Joined:
    Sep 30, 2014
    Posts:
    258
    Are there any thoughts on being able to separately simulate rigidbodies or groups of rigidbodies within the same scene that can interact with each other sometime this year? Would be great if this could be added to the roadmap somewhere.
     
    recon0303 likes this.
  43. Ziflin

    Ziflin

    Joined:
    Mar 12, 2013
    Posts:
    32
    @yant Just to clarify a couple of things related to Physics.Simulate()
    If we were to place all our code in Update (no FixedUpdate), and call Physics.Simulate() at the desired time, this will properly generate OnTrigger and OnCollision events before Simulate() returns? Basically this would allow us to run a per-frame loop similar to:

    * Update
    * Check Input
    * Update Player/AI desired movement
    * Physics. Simulate
    * Respond to triggers/collisions
    * Animation Updates
    * LateUpdate
    * Move Camera
    * Render

    (Basically removing FixedUpdate entirely and placing a per-render simulate where we want it in the main Update. And yes we are fully aware of the issues of passing in variable deltaTime values into Simulate.)
     
    SugoiDev likes this.
  44. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,912
    When you call "Physics.Simulate" (or "Physics2D.Simulate") then the final stage of that is to perform collision/trigger callbacks so yes, you get a simulation step and callbacks prior to it returning.

    The intended use is exactly what you describe.
     
    SugoiDev likes this.
  45. Ziflin

    Ziflin

    Joined:
    Mar 12, 2013
    Posts:
    32
  46. Stanchion

    Stanchion

    Joined:
    Sep 30, 2014
    Posts:
    258
    So is this still relevant with new "Unity Physics" and "Havok Physics"? Are you able to independently simulate bodies in the same simulation and so on? @MelvMay @yant
     
  47. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    290
    Yes, our physx integration will be quite separate from the new physics solutions for the time being. As to the actual feature set available there, I wouldn't be best to comment, unfortunately.
     
    hippocoder likes this.
  48. DavidSWu

    DavidSWu

    Joined:
    Jun 20, 2016
    Posts:
    121
    In our situation we have three cases:
    running at > 20fps (simulate at frame rate)
    running at > 10fps (simulate at 20hz twice per render)
    running below 10fps (Bad situation, simulate at 20hz twice per render, slow down time as MaxDeltaTime does so that we can at least run)

    When simulating 2 steps per frame, it is important for us to have the normal FixedUpdate(), Physics Sim, callbacks occur as normal.

    My current solution is to add the following to the PlayerLoop during EarlyUpdate:

    Code (CSharp):
    1.     const float minFps = 20f;
    2.     const float maxDeltaTimePerStep = 1.0f / minFps;
    3.     const float maxDeltaTime = 2.0f / minFps;
    4.  
    5. static void PhysicsTimeSet()
    6.     {
    7.         var dt = math.min(maxDeltaTime,Time.time - Time.fixedTime);
    8.         var steps = dt > maxDeltaTimePerStep ? 2f : 1f;
    9.         Time.fixedDeltaTime = (dt / steps);
    10.     }
    This allows us to keep the rest of our code the same (other than handling stability when simulating at 20hz and using fixedDeltaTime when approximating time-varying forces like springs, dampers, exponential decay, etc)

    Edit: It seems that Time.time - Time.fixedTime can be used to calculate Time.fixedDeltaTime
     
    Last edited: May 19, 2019
  49. Fergicide

    Fergicide

    Joined:
    Mar 19, 2016
    Posts:
    14
    I did, so let's talk. In my first year of Unity I struggled for a couple months, reading forums and code, trying to figure out this Gordian Knot of FixedUpdate/Update and getting around the stutter. I tried cheating fixedDeltaTime. I tried everything. I almost gave up a couple times after very nearly declaring it an impossibility, that you just could not get smooth mouselook + movement from a rigidbody because of the yin and yang of physics/frame timing. And yet plenty of Unity games were achieving smooth first-person controllers. Plus I did not want to buy an asset and do an end-run around figuring it out.

    When it finally clicked and I realized how things needed to be separated and arranged, and I got perfectly fluid movement with zero stuttering -- and without cheating any Unity defaults -- it was pretty freaking sweet.

    Crank this up to 720p60


    You can tell how excited I am to have solved it by the amount of bunnyhopping I'm doing :)
     
  50. IsaiahKelly

    IsaiahKelly

    Joined:
    Nov 11, 2012
    Posts:
    333
    Glad you solved it, but without some kind of explanation as to how you actually achieved this your post is nothing but a useless brag. It's like somebody saying "Good news everyone! I cured cancer!!" and then just leaving it at that :p. I know you're excited and all, but this isn't even the correct topic or sub-forum. Unless your solution actually uses the auto simulation feature? Some substance here would be great.