Performance Questions

[rosedev]

Hello,

I have two questions on performance.

1) Unity Profiler shows spikes approximately once per second on the Oni.WaitForAllTasks() method, even when the fluid is not moving. Is it normal?
I also checked with ObiProfiler, but I didn't notice anything unusual, except the long "Idle (15ms)" label, which seems to be shown on every spike.
I attached screenshots of ObiSolver, Unity Profiler, ObiProfiler and Emitter material.

2) I have a big level with many (about 20) colliders (some of them are EdgeCollider2D). Does it make sence to disable all colliders which are far away from the fluid? 
I have an idea to fetch the fluid grid each frame using Oni.GetParticleGrid() and disable all colliders that don't contains/intersects with any of the fluid cells.
Something like that:

Code:

  // Solver.OnFrameEnd += UpdateCollidersState;
       private void UpdateCollidersState(object sender, System.EventArgs e)
       {
           var cellCount = Oni.GetParticleGridSize(Solver.OniSolver);
           CurrentFluidGridCells = new Oni.GridCell[cellCount];
           Oni.GetParticleGrid(Solver.OniSolver, CurrentFluidGridCells);

           for (var i = 0; i < Colliders.Count; i++)
           {
               var c = Colliders[i];
               var shouldBeEnabled = false;

               for (var j = 0; j < CurrentFluidGridCells.Length; i++)
               {
                   if (IsColliderAABBIntersectsWithFluidGridCell(c.SourceCollider, CurrentFluidGridCells[j].center, CurrentFluidGridCells[j].size*2)) // compare collider.bounds with cell bounds
                   {
                       shouldBeEnabled = true;
                       break;
                   }
               }

               c.enabled = shouldBeEnabled;
               c.SourceCollider.enabled = shouldBeEnabled;
           }

       }

What do you think, will it increase the performace? I'm asking because I can't test it quickly (I have to change a lot of code to implement that)


Thank you.

[rosedev]

Any update? We are going to release the game soon

[josemendez]

Any update? We are going to release the game soon

Hi rosedev,

1.- Those spikes are probably due to FixedUpdate() being called more than once those frames.

This is the way physics work in Unity (and in any fixed-tilmestep engine): time is accumulated in the regular render update loop (deltaTime), then each frame evenly sized (fixedDeltaTime) chunks are processed. If enough time to require a second (or third, or fourth) physics update in a frame has been accumulated, then that particular frame will take more time to process. Note that this can sometimes lead to a phenomenon called "death spiral" in which the game enters a downwards performance spiral due to too much accumulated physics time, and that Unity offers a way of determining the maximum amount of times FixedUpdate is called in a frame (max fixed timestep) in order to alleviate this. See:
https://docs.unity3d.com/Manual/class-TimeManager.html

2.- Obi only considers colliders that are very close to particles, as it internally uses a hierarchical spatial partitioning structure to store them and determine those that might collide with particles in the particle grid. Static colliders away from particles have zero cost (they aren't even updated). Dynamic colliders away from particles are slightly more expensive as the internal structure has to be updated, but still their cost is near minimal as they generate no contacts. Only colliders actually in contact will particles affect performance.

Anything you do to enable/disable colliders at runtime will most likely only worsen performance.

[rosedev]

Hi rosedev,

1.- Those spikes are probably due to FixedUpdate() being called more than once those frames.

This is the way physics work in Unity (and in any fixed-tilmestep engine): time is accumulated in the regular render update loop (deltaTime), then each frame evenly sized (fixedDeltaTime) chunks are processed. If enough time to require a second (or third, or fourth) physics update in a frame has been accumulated, then that particular frame will take more time to process. Note that this can sometimes lead to a phenomenon called "death spiral" in which the game enters a downwards performance spiral due to too much accumulated physics time, and that Unity offers a way of determining the maximum amount of times FixedUpdate is called in a frame (max fixed timestep) in order to alleviate this. See:
https://docs.unity3d.com/Manual/class-TimeManager.html

2.- Obi only considers colliders that are very close to particles, as it internally uses a hierarchical spatial partitioning structure to store them and determine those that might collide with particles in the particle grid. Static colliders away from particles have zero cost (they aren't even updated). Dynamic colliders away from particles are slightly more expensive as the internal structure has to be updated, but still their cost is near minimal as they generate no contacts. Only colliders actually in contact will particles affect performance.

Anything you do to enable/disable colliders at runtime will most likely only worsen performance.

Thank you for the help! I have one more issue with Obi colliders. Unity Editor crashes when I'm trying to set negative scale to a GameObject with EdgeCollider2D and ObiCollider2D attached. The same happens when I'm trying to set negative scale (x=-1) to the bucket in the sample scene. 
Is there some workaround for this?

Tested with 2018.2.1 and 2018.3 beta

[josemendez]

Thank you for the help! I have one more issue with Obi colliders. Unity Editor crashes when I'm trying to set negative scale to a GameObject with EdgeCollider2D and ObiCollider2D attached. The same happens when I'm trying to set negative scale (x=-1) to the bucket in the sample scene. 
Is there some workaround for this?

Tested with 2018.2.1 and 2018.3 beta

Hi,

We'll test it asap.

However I would recommend avoiding negative scales in general, when using any kind of physics engine. Most colliders will work in different and unexpected ways when using negative scales (crashing is not one of them though, that would be a bug), as that generally turns them "inside out". In the case of a box colliders for instance, it would flip its normals.

Edit: Found the cause of the crash. Only happens to edge/mesh colliders. It is a bug, will provide a workaround as soon as I find one.

[rosedev]

Hi,

We'll test it asap.

However I would recommend avoiding negative scales in general, when using any kind of physics engine. Most colliders will work in different and unexpected ways when using negative scales (crashing is not one of them though, that would be a bug), as that generally turns them "inside out". In the case of a box colliders for instance, it would flip its normals.

Edit: Found the cause of the crash. Only happens to edge/mesh colliders. It is a bug, will provide a workaround as soon as I find one.

Thanks, it would be nice to workaround this problem.  I need to flip an object with edge colliders by horizontal axis and it seems that scaling is the only way to do that in this particular case.