The description for One Way Interaction is as follows:
“If set to true, this body will treat bodies that do not have the flag set as having infinite mass.”
When a physics body with One Way Interaction depenetrates from another physics body with One Way Interaction, it will depenetrate with more force than two identical objects without One Way Interaction. This is contrary to the description, as both objects have the flag set, so should react the same as two objects without the flag set.
This is causing issues when creating destructible objects with One Way Interaction, as those objects explode violently when they simulate, versus those without one way interaction, which break apart with a more realistic amount of force.
I have included photos in the Repro steps. I have attached a video demonstrating the difference in force (the one-way objects are on the right in the video). I have also attached the repro project as described in the repro steps.
Place cubes in a grid so that they are all interpenetrating. I went for a 3x3x3 grid, where each cube is overlapping by 25 cm (see image). [Image Removed]
Set each cube to Physics, Simulate Physics = true.
Duplicate the cubes. Set the duplicates to Physics, Advanced, One Way Interaction = true.
Play the level. Note the way the cubes resolve the interpenetration. The ones with one way interaction travel a greater distance, with more speed. This can be easier to see if you use the Chaos Visual Debugger (Tools, Debug, Chaos Visual Debugger: Record To File, then hit Play In Editor) (see image). [Image Removed]
[mention removed] If I could please ask a further question: What would the performance implications of disabling this optimization be? Do other systems (for example, Niagara mesh particles) use One Way Interaction? Would this optimization be disabled there also? Thank you for looking into this!
As far as I could gather, the only place affected by this change, from EOneWayInteractionPairCollisionMode::SphereCollision to EOneWayInteractionPairCollisionMode::NormalCollision, is ParticlePairMidPhase.cpp (L780):
If the mode is SphereCollision (the default), and there aren’t “TooManyImplicitPairs”, and both colliding particles have one-way interaction enabled, CalculateMidPhaseType returns EParticlePairMidPhaseType::SphereApproximation.
Niagara uses its Collision module, which works based on traces and queries and does not rely on Chaos, so changing this CVAR should not have any implications on Niagara’s performance.
Since you asked, have you observed a different behavior?
If that’s the case, please share a repro project so I can investigate it further in your particular setup.
Thank you for looking into this. I have not observed any different behavior. I was just trying to better understand why this optimization was being made in the first place. From my testing, I have not noticed any performance implications from disabling the optimization.
Thank you for all your help. This CVAR change has fixed my problem, and I am happy for this question to be closed.
I’m not privy to the exact reasoning behind this optimization, but I can make an educated guess that the idea is to save some performance for cases where the size or relevance of particles does not justify the costs of doing the more expensive “normal” collision, but are not so irrelevant that you are just going to ignore the collision altogether.
The compromise sits “in the middle”: treat them as spheres, as that’s the “cheapest” shape to calculate collision.
I can also guess this is something that was born on Fortnite and that Unreal Engine inherited down the road.
I’m glad I was able to help solve your issue.
I’ll close this case then.
If you run into trouble again, don’t hesitate to reach out!