Networked Physics with PhysX

[Blue_man]

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

[Jambax]

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.

Unreal Engine 4 - Server-Authoritative Networked PhysX [Not Available]

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.

[Blue_man]

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.

[Jambax]

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…

[0lento]

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

GetWorld()->GetPhysicsScene()->GetPhysXScene(PST_Sync)->setFlag(PxSceneFlag::eENABLE_ENHANCED_DETERMINISM, true);

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

[Blue_man]

@0lento;660204

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.

\brief Provides improved determinism at the expense of performance.

	By default, PhysX provides limited determinism guarantees. Specifically, PhysX guarantees that the exact scene (same actors created in the same order) and simulated using the same 
	time-stepping scheme should provide the exact same behaviour.

	However, if additional actors are added to the simulation, this can affect the behaviour of the existing actors in the simulation, even if the set of new actors do not interact with 
	the existing actors.

	This flag provides an additional level of determinism that guarantees that the simulation will not change if additional actors are added to the simulation, provided those actors do not interfere
	with the existing actors in the scene. Determinism is only guaranteed if the actors are inserted in a consistent order each run in a newly-created scene and simulated using a consistent time-stepping
	scheme.

	**Note that this flag is not mutable and must be set at scene creation.**

	Note that enabling this flag can have a negative impact on performance.

	Note that this feature is not currently supported on GPU.

[0lento]

@Blue man;660264

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

[Blue_man]

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

[0lento]

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
Flag should be properly set now though.

[Blue_man]

@0lento;660282

I used the same place where all other physics scene flags are set prior to physics scene creation

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

[0lento]

@Blue man;660295

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.

[Blue_man]

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

[0lento]

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

[Blue_man]

Using a fixed physics timestep in Unreal Engine, free the physics approach

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

[0lento]

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.

[Blue_man]

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.

[0lento]

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.

[Blue_man]

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.

[0lento]

@Blue man;660538

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

[Blue_man]

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

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

Thanks, I thought it would just rebuild the project

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.