I am not entirely sure how I feel about this new console command as it stands currently. While batching is always nice and performance improvements are great, even turning this value to 0 (defaults to 1 then due to a Max call) the behavior of updating physics bodies is different than in 4.16 and previous engine versions.
I feel like this is a regression in intended behavior as you would think with the feature essentially turned off that it would behave as it did before (IE not batch or wait to send transform updates).
For instance, if you re-scale an object its physics body won’t actually be changed until the batched commands go through, so you essentially have to wait a frame after setting scale3D to handle any logic that depends on the physics thread scale of the body.
This indirectly breaks any form of fast transform updates to a simulating object.
In 4.16 and before I was able to dynamically re-scale a simulating object while it was held with a PhysxConstraint, however in 4.17 it hitches badly with the same operation. I can directly alter transform on it with its BodyInstance and it has no such problem, however to get the game thread version to also update setting scale3D on it causes the batched physics change to also be called. There is no separate path to manually scaling the physics representation and the object itself due to the UpdateTransform function always being called from SetScale3D and always posting to the physics thread eventually overwriting manual changes to the PxRigidDynamic.
Edit It kind of feels like there is a body lock that doesn’t go away until the actual update happens.
Hello ,
I’ve tried a few things to reproduce the hitches you’re mentioning but I haven’t seen anything on my end. Could you please make an Answerhub post about this in the Bug Reports section and include a project that reproduces the hitch that you’re mentioning?