Calling the physics simulation from C#

@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?

 

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

 

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

 

Hi, did you ever had the chance to share the billards demo?

 

@yant Ping?

 

Hopefully we get an update this year

 

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.

 

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.  

 

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

 

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 ;-).

 

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.

 

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

 

The ability to read code cannot be overstated ;-).

 

I'm quite surprised that Interpolation didn't solve it and made it necessary to run in sync with update.

 

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.

 

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

 

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

 

Yes please (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.

 

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 ;-).

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

@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!

 

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.

 

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.

 

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

 

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

 

@yant This would be great

 

Hi @yant is it possible to use RaycastCommand with a PhysicsScene?

Thanks,
Tom.

 

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.  

 

bumping this thread, @yant it would be great to be able to see that billiards example.

 

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.

 

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

 

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.

 

@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.)

 

Great! Thanks @MelvMay !!

 

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

 

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

 

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

 

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