I have integrated the changelists that were relevant, including the “add to world” changes since there was code to make cleanup of physics state async.
With everything integrated I can say that streaming is better, but there are still a couple key issues that remain for us:
This background task creating a mip seems to stall the RHI which stalls the render thread, which stalls the game thread. This seems to happen quite frequently. Soemtimes the stall is just on TryAllocateInternal, not necessarily CreateNewPool. The fact that we are blocking on these background/async tasks does not seem desired:
[Image Removed]This hitch still occurs despite effectively disabling cvar that should forces the creation of the acceleration structure to block. Is there some other path that this can be blocked?
[Image Removed]Looks like p.Chaos.Simulation.Enable=0 gets rid of most of this, of course that means destruction effects don’t work but 99% of our use case is query only (CMC, traces, overlap queries etc)
Unfortunately the r.GPUCrashDebugging.Aftermath.ResourceTracking CVar is disabled for us so I don’t think it’s the cause of our issue with create committed resource.
I’ll make a new ticket once I have more info on this particular issue.
I would recommend that you create 2 new cases for the rendering and chaos parts. We don’t have a great way to have multiple sets of eyes on the same case and I’ll be less available for a little while because of the UnrealFest next week.
We successfully turned off chaos simulation and just ran a kinematic engine. Honestly for our style of game that’s perfect and it solves a massive amount of streaming related challenges related to building or rebuilding the acceleration structure.
I wanted to take a moment and provide feedback on your team’s approach to async adding bodies however. Is it possible to more granulary write lock the physics engine? Right now those background thread addbody calls are stalling the main thread on any physics queries such as traces or overlaps. It kind of defeats the purpose of putting all the addbody calls on the background thread if there’s going to be such a lengthy write lock in place since the main thread is just stuck waiting.
[Image Removed]
[Image Removed]It seems to me like the lock is initiated for the entire scope of createallbodies when it could maybe be locked per body instead?