Need advice from someone more experienced with Physics regarding performance

Hello guys, I've been working for a while on my game Masters of Puzzle. For some time now I am fighting with a nasty performance problem in the Physics department especially with the larger puzzle tile sets (i.e. 1000 tiles and above). The issue is easiest to observe when the tiles are first packed into the box together. Check this out:



As you can see most of the calculating power is going into physics, but I am not experienced enough with this area to pick an angle to start optimizing.

The structure of each puzzle tile is essentially a single mesh with a compound collider:

There are no triggers or any other event handlers related to physics. Therefore I assume the overhead here comes strictly from Unity native processes handling my configuration of objects.

I know this is a terribly specific situation to my game, but I will appreciate any suggestion on where to start looking for optimization on solving this. I am not afraid to read or dig in deeply, I just don't have an idea what to look for.

Thanks in advance for any help!

 

First things that come to my mind:

• Try Unity 2018.3 (currently in beta). Physics engine has been upgraded and reported to be more efficient in some situations.
• Play with the Physics options (Edit > Projects Settings > Physics), specially: Sleep Threshold, Enable Adaptative Force, Contacts Generation, Broadphase Type.
• Use a single box collider per tile, at least while they're packed into the box. You may keep the compound collider disabled in this situation, then switch to it if the situation requires such precise collisions (i.e. if taken out of the box).

Hope this helps!

 

• If you are enabling and disabling colliders, it causes Physx to create and destroy them, so that's not a great idea.
• In addition you may find really great improvements from using collision layers properly, so that anything that won't collide with something else can be ignored.
• Post more information about the rigidbody, object setup etc

 

First of all, the way you have sliced your object is not optimal: you have 6 boxes, but you can cover all the piece with 4.
Second: if you don't need perfect collisions, use SPHERES. They are by far the fastest collision object.
In your case, you can have 3 boxes and 1 sphere to cover that piece in the image.

Now for the best: you don't need to have all those colliders when the pieces are stacked all together, you can simplify it and use a single box, and only switch to the complex collision structure when the piece is layed down on the floor.

 

Hi guys, thanks for the good feedback! It certainly gives me some ideas to try out and monitor if there is any change in the performance. Moving to Unity 2018, however, might be something of a last resort because it will require effort migrating the TextMesh Pro and some other libraries I use...

In any case, I'll post an update with the results.

Oh, and as requested, here are the component settings for the tiles and the colliders:



And the Physics settings:

 

Changing from Continuous to Speculative for rigidbody in 2018.3 is a help for sure. Also that version of Unity is around 2x faster for physics. Can you give me an idea what code you're doing? any on collision stuff? Also your iterations etc are all set quite high. You also don't allow them to sleep easily.

If you are throwing a lot of puzzle pieces into a jumble at startup, this will cost the most time because physx is creating an internal "island" (a lot of interactions) that's pretty big and it has to solve all that island instead of lots of islands that are smaller.

More info about what you do is helpful, or even a video. Just, at this point there is no bullet for us to offer you, it's about looking at the problem to solve in another way (assuming you moved to 2018.3 for the biggest magic bullet).

 

Hi hippocoder, I will check 2018.3 as well. Hopefully, the migration won't be that painful.

As for the other things, what I do at the beginning is to generate all the tiles inside the bounds of the box. During that generation, the algorithm makes sure to not spawn tiles that overlap in any way (including their colliders) in the 3D space and to also that no tile intersects the box itself. After that, the tiles are essentially floating objects that will drop a very little distance until they settle inside the box. I suspect from my observations that this is the moment where all these collisions take the better of the physics engine. There are no event handlers or any other custom logic linked to collisions. The only thing I have is OnTriggerEnter for the trigger collider of the parent tile object, but that trigger is disabled during this phase, so it should not be firing.

 

Still not getting a clear picture of when or what is happening. Is your problem due to the startup when you create the puzzle ? when the user interacts? Is it VR? and so on. Too little information to help.

I will say that having a low contact offset and sleep threshold is preventing Physx from doing any real meaningful optimisation with large collections like this. It's basically constantly simulating them and making them simulating others. Just something to think about. Adding yet more fuel to the fire is using continuous collision. Should only set it if you need to, then put it back to discrete. Same for interpolation.

You might gain significantly more CPU optimising draw calls as well.

2018.3 allows much more forgiving settings, including Speculative contacts. It also handles fast-rotating objects well.

 

Alright, just recorded a 3-minute video showing the issue. It's a standard desktop game btw, no VR involved. I hope this makes things a bit more clear. As you will see, the problem is at the start of the game but it will continue for a while still and not go away completely even after the tiles have settled completely in the box.

In any case, I will first try adjusting the settings you mentioned. Maybe I am just overkilling it with the values I've set.

 

Is there any code on your part affecting them? OnCollision calls? in any case does seem like 1,000 rigidbodies with compound colliders all colliding at the same time with potential callback with aggressive settings that ramp up processing time isn't helping

Try a sleep of 3 to start, not 0.01.
Have iterations at 1.

Stuff like that. All your settings are overkill for this job.

 

Why it says 17 calls to FixedUpdate? Usually I just see one.

Have you tried changing the Fixed Timestep?

 

Thinking again profiler shows scripts.Update (blue color) taking a lot of time.

Could be 1 update for every 17 rounds of physics, which would explain the performance. 270ms / 17 = 16ms for each FixedUpdate.

Is there anything else in other scripts that could disrupt performance?

 

This happens when the main update takes too long. When this occurs, fixed needs to run more times. You will find this happens to all Unity projects where the frame took too long.

Once he resolves the main bottlenecks he can as a last resort, tweak maximum allowed timestep in time manager. When a frame takes longer than this, Unity disables physics processing. This is an actual last resort though obviously. It's there for those cases where the OS will stall or something stupid happens. It's required because without it, you wouldn't see 17, you'd see 999+ and a crashed Unity in the OP's scenario.

 

Yes, increasing the settings you mentioned improves the performance - the better the higher I set them. But ain't I losing precision of the physics simulation with settings so high? I haven't been able to find a good guide on what settings should be used in a scenario like mine...

As for the scripts part, what I am seeing is that 99% of what is shown in the blue chart is the FixedUpdate call of the puzzle tile objects. I don't understand why it takes such a big chunk of the time, though, because at that point the function does nothing (i.e. no tile is being taken or held at this point):

Code (CSharp):

1. private void FixedUpdate() {
2.    if ( gameObject.GetComponent<Rigidbody>() != null ) {
3.       if ( IsTaken && !IsHeld ) {
4.          ...
5.       } else if ( IsTaken && IsHeld ) {
6.          ...
7.       }
8.    }
9. }

Edit: Actually, after playing around some more, the only significant performance gain from the general Physics settings comes from the Default Contact Offset. The rest of the settings do add some additional boost, but not really that much compared to the offset. Oddly enough, this also decreases the script overhead from the FixedUpdate function. What's the relation here I wonder?

 

You should only activate the collisions between the layers that you need. That could save you a lot.

 

No. With game Physics, the lower the precision you can do, the faster it runs. It's the law of game physics. If you want anything fast, lose the precision, everywhere.

Do less = runs faster.
It works = good.

Keep searching etc because it even explains in the unity manual that default contact offset being set higher is slower, because it will generate (in your case) thousands more contacts that it didn't need to.

The reason insane precision is allowed is because it's relative.Say the simulation was inside a matchbox? it wouldn't be slow if that's all there was.

Do matchbox sized simulation for a planet and you will still be processing when entropy claims us all at the end of time. But don't ignore the other settings. Life is not all about contact offset.

 

Cache your GetComponent(), this will cut some time and GC alloc in editor too.

 

Could you do a little test?

Disable the AutoSimulation and use this yant code.

Code (CSharp):

1. using UnityEngine;
2.  
3. public class BasicSimulation : MonoBehaviour {
4.  
5.     private float timer;
6.  
7.     void Update () {
8.         if (Physics.autoSimulation)
9.             return;
10.  
11.         timer += Time.deltaTime;
12.  
13.         if (timer >= Time.fixedDeltaTime)
14.         {
15.             timer -= Time.fixedDeltaTime;
16.             Physics.SimulateStep(Time.fixedDeltaTime);
17.         }
18.     }
19. }

This is limited to only one FixedUpdate per Update

 

Just to make sure we are on the same page, you mean adding this to the puzzle tile GOs, right? Or to a single object (like the game manager)?

 

Single object

 

Alright, this is the result:

From what I observed, it didn't get better than it is with the current Physics settings and auto simulation on. The only change was that the simulation itself was jittery.

 

Try in https://docs.unity3d.com/Manual/class-TimeManager.html

Maximum Allowed Timestep = 0.1
Fixed Timestep = 0.05

Then for https://docs.unity3d.com/Manual/class-PhysicsManager.html

Sleep Threshold = 5
Default Contact Offset = 0.05
Default Solver Iterations = 1
Default Solver Velocity Iterations = 1
Enable Adaptive Force = true
Contacts Generation = Persistent Contact Manifold
Contact Pairs Mode = Default Contact Pairs
Broadphase Type = Sweep And Prune Broadphase
Friction Type = Patch Friction Type
Enable Enhanced Determinism = false
Enable Unified Heightmaps = true

And yes, 2018.3 beta 3 (or later) is actually required to help this problem.

Personally I would simulate it once then store the rotations and positions of each piece, and set all the pieces to that. Probably would still use above settings even with.

 

I don't know, the profiler keeps pointing several calls FixedUpdate.ScriptRunBehaviourFixedUpdate.

Should be just one, any idea why hippocoder?

 

Only for auto. For auto it will keep calling fixed update repeatedly so x number of steps occur in y time, which is something my above suggested settings try to avoid.

 

AutoSimulation is off, could it be a bug? Unity keeps calling it.

 

Ow, I found it in another post:

FixedUpdate is just a callback, it isn't directly related to physics; it just gives you a callback with a fixed timestep. It'll still get called more than once if it needs to catch up. FixedUpdate will still happen even if you turn off the auto-simulation. It's just that physics won't be called during the fixed update and you are left to call it yourself either in the fixed update or per-frame as you're doing here.

Good to know

 

Honestly, I don't think that you can have thousands of objects all colliding together smoothly, unless you run on a very high end PC.

 

Hi hippocoder, just did a test run with the settings you suggested but the performance is very bad. Also, there are some simulation artefacts (i.e. tiles hanging in the air). Check this out:

It's more or less the same with auto simulation on and off (in which case I use the Physics.Simulate as suggested above). The puzzle tiles have the CCD set to ContinuousSpeculative in this scenario.

Another test I did was with slightly more precise settings in the Physics and CCD set to Discrete. This was way more efficient in terms of performance, but I can't help and wonder what is the tradeoff in picking only discrete CCD, and would it make a difference in my type of game?

 

Discrete is best performance. You get a speculative version in 2018.3 as well. There is no magic bullet left really, so I'm going to bow out. You need to look at precalculating things as well.

 

Very well, thank you for all your help.

 

This truly makes a difference, concerning script execution time. There is an excellent guide on increasing script performance. See: https://docs.microsoft.com/en-us/windows/mixed-reality/performance-recommendations-for-unity