Help How to optimize collisions?

[vrtraining]

So I have turned off surface and self collisions for a cloth and also my sheet is 9x9 = 81 particles. I've tried using many techniques, the sub steps to 1-2, collision iteration is only 1. Using multiple collision layers to avoid multiple collisions. 

The problem im facing is frame rate drop when my cloth falls on the floor as it lay down completely flat on the floor, i think it could be due to all 81 points colliding with the floor. Any other options I can use to reduce physics based processing or increase my framerate? Does total number of colliders in scene effect?

Update: I tried reducing cloth collision points to only 4 and im still getting same results as it hits the floor, looks like number of points colliding isn't the issue. But as soon as it collides with floor my frame rate drops, any way to optimize or trace it? Because as long as im holding the blanket in hand with attachments, it works fine, but as soon a single collision happens or any single particle collides anywhere i get a frame rate drop.

[josemendez]

So I have turned off surface and self collisions for a cloth and also my sheet is 9x9 = 81 particles. I've tried using many techniques, the sub steps to 1-2, collision iteration is only 1. Using multiple collision layers to avoid multiple collisions. 

Hi,

With only 81 particles collision detection shouldn't be a problem - nothing should, really. Performance drops should be expected when dealing with thousands of particles if using the Burst backend, and tens of thousands if using the Compute backend.

The problem you describe sounds quite weird. Off the top of my head, only thing that could cause this is a MeshCollider with lots of small triangles in it, so that each individual particle is spawning an abnormally large amount of contacts. Maybe this is your case?

Also make sure you're not running with the jobs debugger enabled - that will heavily impact performance of all job-based code in your game.

Does total number of colliders in scene effect?

No, particles only consider colliding against nearby colliders.

But as soon as it collides with floor my frame rate drops, any way to optimize or trace it?

Use Unity's profiler. It will tell you *exactly* what the problem is. If you need help interpreting the profiling session, feel free to send it to us and we will help you make sense of the information displayed by the profiler (you can export the session using one of the buttons at the top-right corner of the profiler).


kind regards,

[vrtraining]

Hi,

With only 81 particles collision detection shouldn't be a problem - nothing should, really. Performance drops should be expected when dealing with thousands of particles if using the Burst backend, and tens of thousands if using the Compute backend.

The problem you describe sounds quite weird. Off the top of my head, only thing that could cause this is a MeshCollider with lots of small triangles in it, so that each individual particle is spawning an abnormally large amount of contacts. Maybe this is your case?

Also make sure you're not running with the jobs debugger enabled - that will heavily impact performance of all job-based code in your game.


No, particles only consider colliding against nearby colliders.


Use Unity's profiler. It will tell you *exactly* what the problem is. If you need help interpreting the profiling session, feel free to send it to us and we will help you make sense of the information displayed by the profiler (you can export the session using one of the buttons at the top-right corner of the profiler).


kind regards,

The problem is im using a very optimized fire shuriken particles, frame drops when view port contains fire particles and at the same time if any of a single Obi Cloth particle makes a collision contact.

I have created a fire blanket with Obi Cloth to put off fire. When I use Obi Cloth with the Fire Particles both in my viewport everything is perfect and I'm getting max frames. But as soon as Obi Cloth makes a contact with any collider in scene and my view port contains fire particles, frame rate drops. I get that particles might be drawing some performance but there is no drop in frame rate no matter how much i swing and move my Obi Cloth keeping fire particles in my view port. A single collision cause a drop. And effect is same.

I'm using box colliders in unity scene mostly with Obi Collider Components, yes some colliders are large (like a large floor but its still a box collider)

How Obi Solver works? like Physics is only processed when a single particle comes into contact?

[josemendez]

The problem is im using a very optimized fire shuriken particles, frame drops when view port contains fire particles and at the same time if any of a single Obi Cloth particle makes a collision contact.

I have created a fire blanket with Obi Cloth to put off fire. When I use Obi Cloth with the Fire Particles both in my viewport everything is perfect and I'm getting max frames. But as soon as Obi Cloth makes a contact with any collider in scene and my view port contains fire particles, frame rate drops.

I get that particles might be drawing some performance but there is no drop in frame rate no matter how much i swing and move my Obi Cloth keeping fire particles in my view port. A single collision cause a drop. And effect is same.

That doesn't make any sense whatsoever, shuriken particle rendering and Obi physics collision aren't related in any way.

The only possibility I can think of that would lead to this is that the combined cost of fire particle rendering (possibly due to overdraw?) and collision detection is tipping the update cycle towards death spiraling, forcing more than one physics update cycle per frame.

See the manual for an in-depth explanation of how the physics loop works in games - not just Unity/Obi-, what death spiraling is and why it affects performance.

In any case, the profiler will clearly tell us if this is the case or not.

How Obi Solver works? like Physics is only processed when a single particle comes into contact?

Physics are processed every FixedUpdate (like all physics in Unity), otherwise things would simply not move.

Contacts are generated when particles are close enough to a collider's bounding box, and then solved together with all other physics constraints. So the number of colliders in the scene doesn't have any impact on performance, the number of contacts does.

[vrtraining]

I only see following options, I dont option to disable Jobs Debugger here like its mentioned in your documentation.

[josemendez]

I only see following options, I dont option to disable Jobs Debugger here like its mentioned in your documentation.

Unity 2022.2 /Collections 1.4.0 and up it's in Preferences->Jobs->Enable Jobs Debugger.
https://discussions.unity.com/t/leak-det...eta/899242

[vrtraining]

That doesn't make any sense whatsoever, shuriken particle rendering and Obi physics collision aren't related in any way.

The only possibility I can think of that would lead to this is that the combined cost of fire particle rendering (possibly due to overdraw?) and collision detection is tipping the update cycle towards death spiraling, forcing more than one physics update cycle per frame.

See the manual for an in-depth explanation of how the physics loop works in games - not just Unity/Obi-, what death spiraling is and why it affects performance.

In any case, the profiler will clearly tell us if this is the case or not.


Physics are processed every FixedUpdate (like all physics in Unity), otherwise things would simply not move.

Contacts are generated when particles are close enough to a collider's bounding box, and then solved together with all other physics constraints. So the number of colliders in the scene doesn't have any impact on performance, the number of contacts does.

Here is my profiler data. Im using async option in solver. As soon as physics is invoked from Obi side the rendering is also spiked up. Its due to overdraw from particles but there are very few particles and overdraw works fine if collision is not invoked.

https://drive.google.com/file/d/1LC_wWx2...sp=sharing

[josemendez]

As soon as physics is invoked from Obi side the rendering is also spiked up.

Obi physics is invoked every frame. Collisions are just part of physics, and are also solved every frame (in case there's any).

Its due to overdraw from particles but there are very few particles

Overdraw happens when particles overlap each other in screen space. The amount of particles is largely irrelevant: very few, large articles could cause a huge amount of overdraw, or lots of particles cause no overdraw at all.

A typical problematic case is alpha-blended fog particles where there's few large particles that almost completely overlap each other, to achieve a layered/volumetric fog effect. This requires drawing the same area of the screen over and over - which is what overdraw is. Fire can also be a problem if you rely on large-ish particles that cover the same area of the screen. On the other hand, even if you had thousands of particles you'd have no overdraw issues as long as they don't overlap each other. So a rule of thumb for particle system optimization is to use many small particles that don't overlap instead a few large ones that do, as that will kill performance due to overdraw. This is specially the case when using alpha or additive blending instead of alpha testing.

Of course, camera point of view also plays a role here. If you look at a particle system from afar, you'll get little overdraw since particles cover a very small portion of the screen. If you get up close to the same particles so that they take up most of the screen, you'll get lots of overdraw.

and overdraw works fine if collision is not invoked.

This doesn't make any sense, as I mentioned: overdraw and physics are not related in any way, shape or form. It's impossible for particle drawing to affect cloth collisions or vice-versa.

Your profiler data confirms this: during framerate drops, the only increment in processing time happens in the rendering department. Physics (Obi in particular) always takes roughly the same amount of time. This is apparent if you take a look at Rendering (green) vs Scripts (blue) categories in the profiling graph: Scripts always take roughly the same amount of time, while Rendering considerably increases during framerate drops and causes fps to dip around 40-45 fps.
Taking samples of 2 specific frames to compare timings:

No framerate drop:

Obi: 2.23 ms
Rendering: 3.29 ms

During framerate drop:

Obi: 2.13 ms
Rendering: 18.07 ms(!)

As you can see Obi takes exactly the same amount of time in both samples, around 2ms. The only difference is that rendering is x6 costlier during framerate drops. 

So the problem is clearly not Obi, but something that happens during rendering.

[vrtraining]

Obi physics is invoked every frame. Collisions are just part of physics, and are also solved every frame (in case there's any).


Overdraw happens when particles overlap each other in screen space. The amount of particles is largely irrelevant: very few, large articles could cause a huge amount of overdraw, or lots of particles cause no overdraw at all.

A typical problematic case is alpha-blended fog particles where there's few large particles that almost completely overlap each other, to achieve a layered/volumetric fog effect. This requires drawing the same area of the screen over and over - which is what overdraw is. Fire can also be a problem if you rely on large-ish particles that cover the same area of the screen. On the other hand, even if you had thousands of particles you'd have no overdraw issues as long as they don't overlap each other. So a rule of thumb for particle system optimization is to use many small particles that don't overlap instead a few large ones that do, as that will kill performance due to overdraw. This is specially the case when using alpha or additive blending instead of alpha testing.

Of course, camera point of view also plays a role here. If you look at a particle system from afar, you'll get little overdraw since particles cover a very small portion of the screen. If you get up close to the same particles so that they take up most of the screen, you'll get lots of overdraw.


This doesn't make any sense, as I mentioned: overdraw and physics are not related in any way, shape or form. It's impossible for particle drawing to affect cloth collisions or vice-versa.

Your profiler data confirms this: during framerate drops, the only increment in processing time happens in the rendering department. Physics (Obi in particular) always takes roughly the same amount of time. This is apparent if you take a look at Rendering (green) vs Scripts (blue) categories in the profiling graph: Scripts always take roughly the same amount of time, while Rendering considerably increases during framerate drops and causes fps to dip around 40-45 fps.
Taking samples of 2 specific frames to compare timings:

No framerate drop:

Obi: 2.23 ms
Rendering: 3.29 ms

During framerate drop:

Obi: 2.13 ms
Rendering: 18.07 ms(!)

As you can see Obi takes exactly the same amount of time in both samples, around 2ms. The only difference is that rendering is x6 costlier during framerate drops. 

So the problem is clearly not Obi, but something that happens during rendering.

Thanks for taking the time to analyze my profile data. In profile it seems that rendering is taking extra time but thats what confusing for me why a physics action is triggering extra rendering? I'm attaching a gameplay video here.

https://drive.google.com/file/d/1GHb1tZT...sp=sharing

You can see fire particles infront of you as soon i move the obi cloth blanket forward and it touches the fryer (not fire particles collision, but the box collider with obi collider that is covering the fryer which is emitting fire) the framerate drops.

Fire seems to be working fine, you can see Frame rate locked at 71-72 when I hold Obi Cloth and view the same fire, but as i move the Obi cloth forward and it collides with Box collider the frame rate drops. Its only happening on collision. When I pull back the Obi cloth from collider the framerate is restored.

I debugged and enabled disabled everything since last 2 days in project, it only happens when Obi cloth makes a collision contact. Is it possible that Obi collision is causing cloth rendering to increase? that could be a reason for extended rendering? Did you checked the physics part of the profiler? The framerate drop and physics curves are proportional



High res image at https://yourimageshare.com/ib/OJVYkkwGtO

[josemendez]

Fire seems to be working fine, you can see Frame rate locked at 71-72 when I hold Obi Cloth and view the same fire, but as i move the Obi cloth forward and it collides with Box collider the frame rate drops. Its only happening on collision. When I pull back the Obi cloth from collider the framerate is restored.

This doesn't mean much. When you pull the cloth towards the fire, fire particles cover a larger portion of the screen. As you pull the cloth away, it occludes part of the fire. In other words: there's more fire rendered when the cloth is over the fire. Could -or could not- be the cause, but cloth collisions certainly don’t seem to have anything to do with this.

I debugged and enabled disabled everything since last 2 days in project, it only happens when Obi cloth makes a collision contact.

There's a very simple test you can do: disable the ObiCollider component in the frier's box collider. Does the fps drop still happen? If it doesn't, it does have something to do with physics. If it still happens, physics don't play any role in it.

Is it possible that Obi collision is causing cloth rendering to increase? that could be a reason for extended rendering?

Not possible. Physics and rendering are two completely separate processes that can't affect each other unless you explicitly tie them together (eg. rendering more stuff in response to a physics event).

Did you checked the physics part of the profiler?

Yes, physics takes exactly the same amount of time (around 2.2 ms) throughout the profiler's timeline as showed in the analysis above.

The framerate drop and physics curves are proportional

The thing you're looking at is Unity's built-in physics. The curve in question is trigger overlaps, it goes from 4 to 17 which means that a lot more triggers are overlapping when you move the cloth towards the fire. This has nothing to do with Obi, but if you're doing something rendering-related in response to triggers this may be a clue to what's happening.

At least according to your profiler data, Obi's physics "curve" is absolutely flat while the framerate drop and rendering curves follow each other closely. The top line is rendering, the bottom one is Obi physics (which are listed in the “Scripts” category). You can clearly see Obi takes consistently the same amount of time while rendering goes up and down between 70 and 50-ish fps: