Calling the physics simulation from C#

What has been proposed so far is not enough to do anti lag networking. Networking would benefit greatly from being able to raycast into the past on the server with a provided time stamp.

This would require maintaining old spatial partitioning data structures.

 

Are you sure it's not enough? We can maintain that data manually

Actually, seems to me like we should maintain it manually, because otherwise the physics engine would have to move all the rigidbodies in the scene back and forth at every single "RaycastAtTime" we call. It also wouldn't make sense for the engine to keep track of all that in the background when many projects won't need that and the considerable overhead that comes with it

 

I agree that we should be maintaining history information ourselves, but what was lacking (heard a rumor its automatic in newer versions), is the ability to invalidate the spatial partitioning graph after performing a rewind without having to wait for the next frame.

Being able to manually call Physics.Simulate(0f) would likely achieve this, but I would imagine there could be a lighter version that only recalculates the spatial partitioning and doesn't attempt to integrate anything.

 

Multiple physics worlds may solve the issue (depending if initializing a new physics world is fast enough and sets everything up correctly to be able to return correct values for raycasting/collision detection).

 

The better solution is for unity to maintain a buffer of past spatial partitioning states say 2 secs back. Then you can have a raycasting overload which takes a time stamp. If the time stamp is too old simple raycast vs the oldest state. Raycasts do not require dynamics and these tests need to be done on the server. This is how other games do it.

Otherwise the user needs to reimplement raycasting in order to rewind time on the server. Brute force is not a good solution here because the number of bullets fired can be high and they all have different time stamps.

I have already reimplemented raycasting in my project because of this. I will tell you right now that unity is in a better position to do this then we are. However I doubt it will ever get done by Unity.

 

As I mentioned earlier, the problem with this approach is that there will be a cost for going back in time at each physics query you make. Also let's say you do a "RaycastAtTime" in the past, and it hits.... how do you resimulate from there? This doesn't really solve any problem.

A better alternative, if you really want Unity to handle all this in the background, would be to have some methods to restore the physics world to a given time. Something like this (code may not be 100% accurate but it's just to give an idea):

Code (CSharp):

1.  
2. void OnSomeEvent(float timeOfEvent)
3. {
4.     if (Physics.SetWordToTime(timeOfEvent))
5.     {
6.         // Do 20 raycasts and Physics Overlap here
7.         // (...)
8.  
9.         // Resimulate to present
10.         Physics.Simulate(Time.time - timeOfEvent);
11.     }
12.     else
13.     {
14.         // what happens if the 'timeOfEvent' is not in our world snapshots buffer?
15.     }
16. }
17.  

But I still disagree with having Unity handling this automatically in the background. This will induce a huge additional overhead for anyone who doesn't use this feature. Unless... there is a parameter somewhere in the physics settings that lets you choose the amount of time where world snapshots are conserved. And it is at 0 by default

But then you still have to handle these things manually for kinematic character controllers, projectiles, moving platforms, and anything that isn't just a plain old rigidbody. So in the end, there's no way to avoid handling this manually. I'm not sure what you mean when you say that would be "brute force". It's just the way things are supposed to be

 

@PhilSA you seem very confused on how physic engines work and how networking is done in real games. And yes maintaining a parameter for how long snapshots are stored is trivial.

No one reSimulates that way because of determinism.

Some games do run physics on the clients many do not. Those that do use client side prediction only and get corrections from the server. Many uses different forms of dead reckoning which is good enough for dynamic objects over a short time frame and then blend back.

 

It's just a quick example that doesn't really do anything. The point was that having just a "RaycastAtTime" is a bit pointless and also inefficient, and that what you actually need is a way to restore the world to a certain time, and THEN do your operations and your custom re-silumation that takes all the player inputs and everything else.

Then, my second point was that you'd have to maintain world snapshots manually anyway, because not everything that moves will be a rigidbody

 

No what? kinematic colliders are also part of the physics state. You need to study networking more.

Physx is not deterministic and no one networks this way. The server is god and it runs the physics. Deterministic networking is a thing but only really for RTS games. The more determinism the better for all networked games but it is not relied on to sync states.

The clients are all smoke and mirrors, anti lag networking is also never 100% just better then without.

 

What about plain transforms that are moving around and do some logic? Like an energy ball that can destroy the physics objects that are in its radius? Or prevents shots/visibility from going through it

And how would the automagical solution know which objects to pick, if you don't want it to keep track of everything for performance reasons?

 

What auto magic are you are talking about? All you are going is raycasting vs the position and rotation of old physics states.

You still need to do a lot of low level networking here.

 

Allright let me ask a different question: How would you use the Physics.Simulate() method for networking if you don't have a method to go back in time, and re-simulate from there?

The raycasting methods you are talking about do not reset the world back to a previous state. They just query information about a previous state. But if you want to resimulate the physics from a point in time (with new inputs/conditions/etc), you have to restore a previous world state first, no? Querying information about a past state isn't enough

 

There are already packages with solutions for lag compensation such as Photon Bolt, more important is separate physics groups that can be subject to manual control. Proper solutions for client side prediction of rigidbodies will not be possible until Unity does this.

 

It shouldn't be up to Unity to write your game for you, everyone has different requirements. If the sufficient APIs are exposed we can
A) Roll our own solution
B) Buy an asset that suits our specific use case

The only reason Unity should be providing closed source features are if it is unfeasible to do in C# due to perf overhead or the feature requires tight editor coupling that gets too messy in plugins.

Agreed. Sounds like they are getting close too
https://forum.unity3d.com/posts/3052958/

 

Sorry for a dumb question, but is Unity Physics (or PhysX) cross-platform deterministic?
I want to avoid rigidbodies synchronization (or do it as rare as possible) in my network game.
Will the simulations be equal on different platforms with forces applied on equal time frames across all parties?
Is it achievable at all? Or maybe with some workarounds/restrictions?

 

PhysX isn't even deterministic on the same platform.

 

I'm loving this feature it works really well, I can easily keep track of the moving objects myself to reset there position and play them forward again. No as I have a very large space I have trouble with floating point accuracy it would be good to be able run multiple instances of the physics engine in the same server( although I'm currently considering using containers and running separate server code instances)

 

I found this thread while trying to figure out how to do lag compensation with Unity's physics. Being able to manually set up colliders, run a timestep, and then check for overlapping colldiers and performing raycasts allows me to do this.

I don't use collisions where things bounce in my net code because it is not deterministic. However I still would like for some purely decorative objects to use collision. I'm finding this hard to run when a timestep runs for every rigidbody in the game.

This is just another voice saying it would be nice to be able to simulate separate physics worlds independently of each other. Thanks for working on this!

 

Have you considered physics layers?

 

I found a hacky way of working around the fact that you can't step physics for specific rigidbodies or groups or rigidbodies, so I managed to get an initial working version of server authoritative rigidbodies with clientside prediction.

And my hack to make stepping work for specific rigidbodies
https://hastebin.com/ixodedexac.cs

 

I would like to use unity to train a neural network that understands the physics in the unity game by running a massive amount of simulations. Previously, unity was limited to a max time speed up of about 100 and I was wondering if I can use this new physics.simulate to speed up time so that the physics could run simulations above the time.timescale=100 limitation?

 

Hi! Thank you very much for making Physics.Simulation call public!
Although it may perform better: for one cube calling Simulate() 100 times takes 10 ms on PC, which is a wierdly big number because guess how long it takes to simulate 16 cubes? The same 10 ms.

Probably the most common use of resimulating physics is to apply client-server reconcillation, so it would be very useful to make 30-60 physics steps (in case user has temporarily bad connection) without causing a huge spike. Common technique is to update only the client's character and save priceless milliseconds. But in this case it doesn't help, because simulation for 1 player takes up the same time as simulating for 16 players

 

Although I'm curious about the 10ms thing, I doubt Physics.Simulate was meant to be used in the case of simple lag compensation for player characters. I think it's more for the kind of situation where you have to do lag-compensation for all physics objects in your world. So let's say you have a bunch of physics boxes flying around, and when you try to shoot another player, one of the flying boxes blocks your shot. With Physics.Simulate, you can go back in time, apply the shot's force to the flying box, and then resimulate to find out what kind of physics chain reaction that box would've caused due to it resimulated change in trajectory.

But in the end, for player characters, it's still a much better idea to do a custom system I think

 

Lag compensation != client side prediction / reconciliation

 

I haven't had a chance to test this new functionality out yet but I do have a few questions about it.

1) Will passing a negative timestep value step the physics simulation backwards?
2) Is the simulation perfectly symmetrical?

WIth question 2, imagine I have a cube that I apply various different impulse forces to it over several frames. If I now step the simulation backwards does the engine undo those impulse forces as I applied them in the past, or does it simply extrapolate the current velocity and step backwards.

If the simulation is symmetrical then, how far back does the engine cache this kind of information accurately? How far back can we wind a simulation and then wind it forward and expect to be at the same state prior to rewinding?

 

Sorry guys. I've been following this post for a long but I have a question before I update to Unity 2017.

What if I want to quickly know where the Rigidbody object will be in 2 seconds, in 3 seconds and 5 seconds.

Will these simply do it?

Code (csharp):

1.  
2. Physics.Simulate(2);
3. //Get position
4. Physics.Simulate(3);
5. //Get position
6. Physics.Simulate(5);
7. //Get position
8.  

OR Maybe this?

Code (csharp):

1.  
2. IEnumerator findFuturePos()
3. {
4.     timer = 2;
5.     while (timer >= Time.fixedDeltaTime)
6.     {
7.         timer -= Time.fixedDeltaTime;
8.         Physics.Simulate(Time.fixedDeltaTime);
9.     }
10.     //Get position
11.  
12.     timer = 3;
13.     while (timer >= Time.fixedDeltaTime)
14.     {
15.         timer -= Time.fixedDeltaTime;
16.         Physics.Simulate(Time.fixedDeltaTime);
17.     }
18.     //Get position
19.  
20.     timer = 5;
21.     while (timer >= Time.fixedDeltaTime)
22.     {
23.         timer -= Time.fixedDeltaTime;
24.         Physics.Simulate(Time.fixedDeltaTime);
25.     }
26.     //Get position
27.  
28.  
29.     yield return null;
30. }
31.  

If not, is this even possible with this new function? This is the only reason I want to update my Unity 5.6 to 2017 but I want to make sure that it works or it is possible before doing so. Thanks.

 

@hangemhigh Haven't tested that specifically, but I don't see why it shouldn't work. One thing to note is that simulate will move your bodies, so if you don't want to actually move to that new position, but just show a ghost of where it would be you need to make sure you reset to the initial state when you're all done.

Eg.
//store initial stateof body (pos/rot/vel/aVel)
Physics.Simulate(1f);
//Get position
//restore body to initial state

 

@Manmax75 Haven't tested putting in a negative timestep, but there is no built in rollback. If you want to roll back to a previous state you need to store that data and handle it yourself.

 

Thanks for the reset position advice. I didn't even know this.

Remember that I have two examples, which one are you referring to when you said "I don't see why it shouldn't work"?

The first or the last example or maybe both?

 

@hangemhigh Both seem like they would. The first example is more simple, though. Just would need to add a way to rewind back to your current state after you grab the "future" position.
If you're wanting to know the position of an object at 2, 3, and 5 seconds from the current time I'd suggest something like this.

//Store state of the object at the current time (start time),
//Simulate(2f) to simulate 2 seconds from the current time
//store the state of the object(2f). Current physics time is now at startTime + 2f
//Simulate(1f). Since the physics time is now at startTime+2f, this will put you at startTime+3f.
//store the state of the object(3f)
//Simulate(2f). Since the physics time is now at startTime+3f, this will put you at startTime+5f.
//store the state of the object(5f)
//Restore the state back to the start time. (via setting the pos/rot/vel/aVel back to whatever it was)

It's important to note that every time you call Physics.Simulate EVERY body will be simulated at once. There are some posts in this thread on how to only step one rigidbody, not the entire simulation though. If you have multiple physics object, you need to store the state for them all at the start, and restore to that state when you're done "looking into the future".

 

Ok. Thanks for the info.

It is interesting that it says this "Using step values greater than 0.03 is likely to produce inaccurate results." on the Physics.Simulate page. I will give this a try by the end of this week and put some comments if I run into issues.

 

Yes. Simulate just runs a physics step with the timestep provided. If you expect that to be accurate, that must be the same tilmestep your game uses. If you need to simulate for longer than one tilmestep, you will need to loop.

Edit: I do wonder how on earth "timestep" became "tilmestep" twice in a row...!

 

Hello guys. Related to this post, I have just developed an object scatter that will allow you to automatically place object around with physics. It includes also other cool features (imho )

Apologize if this is considered a shameless spam, but I do think it is related and I actually got some info from this post for building it. For screenshot and video see here: https://forum.unity3d.com/threads/p...-the-editor-with-physics.488909/#post-3189060

 

Trying to understand if Physics.Simulate() can fix my problem – I'm trying to implement a friction on some ConfigurableJoints I have in a project. Basically, the joint has all the normal restrictions plus a "friction force" which subtracts a fixed magnitude of angular velocity (and the corresponding linear velocity based on the offset of centerOfMass to joint connection) in the opposite direction of current movement.

The problem lies in making sure this friction is subtracted from the final velocities AFTER all other forces are applied in the various FixedUpdates (joint connection forces, external "explosions" from other objects in the scene, etc.) as well as the automatic unity forces (gravity, collisions). There's several limitations:

1) There's no PostDragAndCollisionsUpdate, or even a LateFixedUpdate for that matter (I guess you could do script ordering but I'm trying to avoid it).

2) You cannot grab the net velocity added to a rigid body so even if I hack a LateFixedUpdate there's no way to get what the final velocity will be (not to mention gravity, drag, and collisions have not yet been applied).

Looking at this thread and testing on my own I discovered the order of operations to be

1. Call FixedUpdate() for all objects.
2. Apply the net velocity from all received AddForce/AddTorque calls
3. Apply drag and angular drag
4. Apply collision forces

So my question is, how many of these steps are still hidden inside Physics.Simulate()? It sounds like FixedUpdate calls are still outside (and I imagine collisions are stuck inside) but what about drag and angularDrag? If I adjust the execution order for a CustomSimulationScript to be last can I create a pool of my joint objects and grab their final velocities somehow, apply my own drag formula (the friction), and then call Physics.Simulate()?

If not, would it be that difficult to expose the necessary information on Rigidbodies? Right now I'm simply acting on the final velocities from last frame and reverse engineering the required angularDrag and drag. It works okay-ish until there's a significant change in velocity and weirdness ensues.

My conclusion at this point is that it's impossible to get this working clean. Please show me how I'm wrong

 

Unfortunately, all of this is still hidden inside Physics.Simulate().

But since your custom drag happens on the final velocity after all forces/collisions are applied, you should be fine with just making yourself a LateFixedUpdate() after calling Physics.Simulate(), and handling it in that. Although.... the effect of the drag will always be one frame late. It may end up being unnoticeable.

I understand that what you'd really need is a point where the final resulting velocity for this update has been calculated, but not yet applied as movement (right?). I actually remember a situation where I really would've wanted that for making custom character controllers. I ended finding a solution indirectly through ComputePenetration, which allowed me to solve my own collisions whenever I wanted and therefore make my own physics, sort-of. But this solution may not really apply to your situation since you're using joints

 

Oh... my... god... you're totally right. The instability in my current implementation only gets out of hand because I'm hacking the drag which is taking a percentage of the wrong frames velocity, while your solution takes the exact needed velocity change and simply applies it later (so the error doesn't scale over time).

In fact, does Physics.Simulate() actually setup the interpolation or does it merely adjust the velocities (and position in the case of collisions)?

Couldn't I just update the rb.velocity and rb.angularVelocity on my pool of joints after calling Physics.Simulate()?

 

Simulate() calculates the final velocities and applies the actual movement, but I'm not sure about interpolation. We'd have to test that.

yup. I think that'd work

 

So I figured out the order of things:

1. Physics.Simulate() updates the cached end point for the actual physical movement whenever you choose to call it.
2. Rigidbody uses currently cached physical end point and calculates the selected interpolation for given Time.deltaTime (after FixedUpdate but before Update)
3. Update() methods are called after that frames interpolation value has been applied to the transforms.

I setup a manager that registered Rigidbody's and set their velocity and angular velocity to zero each Update/FixedUpdate after calling Physics.Simulate(). Below are the two separate setups I chose (commenting the other out when testing)

Code (CSharp):

1.   //Scheduled to trigger BEFORE all other Updates()
2.    void Update ()
3.     {
4.         if (Physics.autoSimulation)
5.             return;
6.  
7.         mTimer += Time.deltaTime;
8.         if (mTimer >= Time.fixedDeltaTime)
9.         {
10.             mTimer -= Time.fixedDeltaTime;
11.             Physics.Simulate(Time.fixedDeltaTime);
12.  
13.             if (mLateFixedUpdateGameObjects != null) {
14.                 for (int i = 0; i < mLateFixedUpdateGameObjects.Count; i++) {
15.                     Rigidbody[] rbArr = mLateFixedUpdateGameObjects [i].GetComponentsInChildren<Rigidbody>(false);
16.                     for (int j = 0; j < rbArr.Length; j++) {
17.                         rbArr [j].velocity = Vector3.zero;
18.                         rbArr [j].angularVelocity = Vector3.zero;
19.                     }
20.                 }
21.             }
22.         }
23.     }
24.  
25.    //Scheduled to trigger AFTER all other FixedUpdates()
26.    void FixedUpdate ()
27.     {
28.         if (Physics.autoSimulation)
29.             return;
30.  
31.         Physics.Simulate(Time.fixedDeltaTime);
32.  
33.         if (mLateFixedUpdateGameObjects != null) {
34.    
35.             for (int i = 0; i < mLateFixedUpdateGameObjects.Count; i++) {
36.                 Rigidbody[] rbArr = mLateFixedUpdateGameObjects [i].GetComponentsInChildren<Rigidbody>(false);
37.                 for (int j = 0; j < rbArr.Length; j++) {
38.                     rbArr [j].velocity = Vector3.zero;
39.                     rbArr [j].angularVelocity = Vector3.zero;
40.                 }
41.             }
42.         }
43.     }

I then put a script on a chain of ConfigurableJoint's that constantly applied smooth varying force and torque.

Update() - Failed to cancel all the velocity. It slowed the velocity to a small speed (it was letting one frame of force through). Additionally, the movement was jittery and the physics behaved differently.

FixedUpdate() - Also let one frame of force through but was not jittery.

This is why I think the smoothing is done between FixedUpdate and Update but it uses cached values from when Simulate was called. Luckily, you can just detect when the friction brings it to zero and call Sleep() on the Rigidbody after a certain number of frames (and maybe raise the drags on registered rigid bodies to slow them as they count to sleep).

 

FWIW, there actually sort of is a LateFixedUpdate built into the engine, it was just misdocumented for years.
yield return new WaitForFixedUpdate() returns after the physics step and all collision callbacks but before the next FixedUpdate or Update. They have updated the docs to reflect that.

 

That is a nicer point for my solution because even putting it as the last FixedUpdate doesn't come after the OnTriggerXXX OncollisionXXX callbacks but WaitForFixedUpdate() does. Thanks!

 

I was just coming looking for something like this and wow its already in the version i have Awesome. I needed it because I need deterministic physics for non random gameplay so that you can have replays where you pause and slow down the game without effecting the fixed timestep size because things calculate in between time steps. Example is this enemy close enough to auto attack it.

 

@yant
Is it possible to get the position in just one frame. I want to know the position of rigidbody after 3 secs but Physics.Simulate have only timeStep as parameter. I will have to loop it with update or coroutine.

When I try to use for-loop in one frame it freezes the main thread. And we cannot even use other thread for calling Simulate method.

Is there any other way I can get the position in advance without freezing Unity Main thread ?

 

I am Having same issue , have you done it @hangemhigh ?

 

I think you really do need to call Simulate() several times in a loop with the regular physics timestep as parameter. Otherwise you'll get different results than what really would've happened (as I try to picture below )


For the main thread blocking problem, I don't think there is much we can do except:
- Wait for the ability to simulate only individual rigidbodies or rigidbody groups (so it'll cost way less for the main thread)
- Wait for jobified 3D physics (2D physics jobification already in progress: video )
- See if your situation is eligible for making custom physics that you can simulate yourself. For instance, if this is for planning the trajectory of a golf ball, it would probably be a good idea to make your own deterministic simulation for the golf ball (using sphereCasts, overlapSpheres, computePenetration, etc....).

 

So is this ever coming to Unity or nah?

 

Hi there!
Is it possible to make Simulate in thread?

 

Is partial scene simulation still planned? Is it not possible due to PhysX?