Networked Physics with PhysX

Did you add PhysX and APEX to your build.cs?

Figured it out… just needed to include PxScene.h directly (doh)

EDIT: Okay so I currently have this working in a PIE session, without fixed timesteps. I’ve tried with 250ms latency, and it seems to be semi-reliable. Bad moves are made more often the more lag you get, but that’s probably pretty normal. Will upload a video in a sec.

EDIT 2: Boom! This has no smoothing and isn’t using fixed timestep.

Just found this in the release notes for PhysX 3.4:



- Introduced a new enhanced determinism mode. See PxSceneFlag::eENABLE_ENHANCED_DETERMINISM. This provides additional levels of rigid body simulation determinism at the cost of some performance.
- New "immediate mode" API has been added. This exposes access to the low-level contact generation and constraint solver, which allows the application to use these PhysX low-level components to perform its own simulations without needing to populate and simulate a PxScene.


This might help out with resyncs quite a lot, though I suspect we’ll need a source engine build in order to set the determinism flag.

You got pretty good results, my only problem with resimulation is that my vehicle goes out of sync when it is free falling. If you just let a physics body to fall you will almost every time get a different rotation and that is my problem now. Determinism option might help a lot, I wonder if it would be possible to expose determinism mode to project settings and submit it as a pull request.

To be honest if someone could submit a PR for that anyway and expose it to project settings (theoretically fairly simple), I would upvote the **** out of it.

I would do it, but I find Git a nightmare to work with. I also never know which branch we’re supposed to submit PR’s too…

It seems like it could be set with just one line (or few if you actually do some safety checks for getters)

I haven’t validated this though, just what I found.

In the PxSceneFlags it says that this flag has to be set at scene creation. I think UWorld is responsible for scene creation (not sure) so maybe with a little bit of source changes this can be added there.

Oh I missed that one! Good catch. Yeah, it shouldn’t require big change but definitely would require engine source code modification in this case.

I can make a PR about this but not sure if it’s really that useful considering that ue4 ticks physics at variable time step anyway (so it’ll not be deterministic by nature anyway).

I would try to add it but I have no idea how to submit a PR.
Edit: Didn’t see your previous post :stuck_out_tongue:

I made the change to the engine already. I used the same place where all other physics scene flags are set prior to physics scene creation, but I have no clue how to test it’s actually doing things differently :slight_smile:
Flag should be properly set now though.

In which class is that, UWorld? I can test it on my replay/rewind system.

https://github.com/0lento/UnrealEngine/commit/31c1211c8d88e7f0274e350c4f8f7a8fa48e2dc4

I’m still testing that this works properly. If I don’t see anything breaking, I’ll send a PR out of that.

Thanks, I don’t why I thought that it was in UWorld :stuck_out_tongue:
I will build the engine and when I test my project I will let you know here if I notice any improvements.

Here’s the PR:
https://github.com/EpicGames/UnrealEngine/pull/3194

Do note that you’d still need to have fixed timestep for this to make any noticeable change (either by modding how the substepping works or at least by running ue4 at fixed frame rate). Now we need someone to make a PR for that fixed time stepping =D

@Snowcrash5 Made a tutorial on how to enable fixed timestep, I just downloaded ue4 source and built it. I will try to implement it tomorrow by following the tutorial if Snowcrash5 has nothing against using his tutorial to submit a PR.

I need to get that engine contributor badge :rolleyes:

Oh I already started on that fixed timestep PR too using the most trivial method…
I’ve done this change years ago and actually pointed Snowcrash5 into right direction when he was doing that himself. I’d do some things bit differently than how he did on that tutorial though.

The core reason why I didn’t make the PR for this back then was that you’d still have some smoothness issues as physics will not be in perfect sync with your rendering anymore. There’s a way to solve it but it’s not that simple anymore as it would require a lot more thought.

It is nice to get this things finally started. It is better you make a PR, you probably have more experience with physics than me. Anyways I will test that determinism flag with fixed timestep just to see if it makes any difference.

Here’s a small status update on this:

I got the core implementation done for the fixed timestepping with a fallback to variable timesteps (in case there’s too many substeps between rendered frames to make sure your CPU won’t starve).

I made two gifs to visualize the difference between variable and fixed timestepping (I won’t embed the gifs as they ended up quite big in filesize):

1. Here’s what stock UE4 physics sim looks like when you keep hitting PIE (3 runs in this gif).
2. This is what they look at fully fixed timesteps without the fallback (3 runs in this gif).

But… the reason for the other gif being without the fallback is that I found out that fallback messes up the determinism in PIE if you start simulation on Begin Play. This is happening because first two ticks have huge DeltaTime in PIE and while physx is more deterministic after those two frames on following fixed timesteps, simulation is already off by doing those two first ticks using variable physics steps. This means that you don’t visually notice the determinism anymore when you compare the results by looking at different PIE runs. Do note that this isn’t a big issue when the game is already running properly, it’s just one of those things that make people think the thing is not working properly when they try it out.

That being said, I’ll be implementing next a dynamic limit for the max substeps (for fixed timestepping only). This way the fixed timestep simulation can temporarily exceed the max substep limit by some bigger amount as long as it doesn’t keep doing it for every frame. This would still prevent the potential starvation issue and should be more flexible without falling back immeatidly if single frame makes the max substep count to exceed.

One additional issue I found was with the way UPROPERTIES are setup while trying to make a nicer setup for this on project settings. Apparently there isn’t any clean way I can use EditCondition for two booleans at once. I’d like to have a separate value for fixed timestep duration instead of reusing MaxSubstepTime (as it could be confusing to users to use the same with that name). But I can’t set for example the MaxSubstep time the following EditCondition = (bSubstepping && !bSubsteppingFixedTimestep). There is a workaround for this but it’s not very clean IMO.

Wow, that is a big difference, also do you maybe know why is visual studio rebuilding the whole engine (source build) when I just clicked on the project to rebuild.

Difference is big on that test, but I also made a test setup that I knew beforehand to be definitely off if you wouldn’t use fixed timesteps. It’s still not 100% the same on fixed timestep either but it’s way closer already.

To the rebuilding issue, don’t hit rebuild, hit build and it will only build the changed parts. Rebuild will rebuild everything like the name implies :slight_smile:

For now I just implemented what Snowcrash5 showed in his tutorial just to see the difference.

Thanks, I thought it would just rebuild the project :slight_smile:

After implementing fixed timestep from the tutorial the editor just freezes after I hit play.

@TheJamsh I found out how to create a new physics scene, still not sure how to copy the settings from the main scene.


GPhysXSDK->createScene(PxSceneDesc)

To insert an actor you have to get the PxActor from FBodyInstance.