(15-10-2024, 06:05 PM)vrtraining Wrote: 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. 

(15-10-2024, 06:05 PM)vrtraining Wrote: Does total number of colliders in scene effect?

(15-10-2024, 06:05 PM)vrtraining Wrote: But as soon as it collides with floor my frame rate drops, any way to optimize or trace it?

(16-10-2024, 08:11 AM)josemendez Wrote: 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,

(16-10-2024, 08:38 AM)vrtraining Wrote: 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.

(16-10-2024, 08:38 AM)vrtraining Wrote: How Obi Solver works? like Physics is only processed when a single particle comes into contact?

(16-10-2024, 08:51 AM)vrtraining Wrote: I only see following options, I dont option to disable Jobs Debugger here like its mentioned in your documentation.

(16-10-2024, 08:49 AM)josemendez Wrote: 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.

(16-10-2024, 11:06 AM)vrtraining Wrote: As soon as physics is invoked from Obi side the rendering is also spiked up.

(16-10-2024, 11:06 AM)vrtraining Wrote: Its due to overdraw from particles but there are very few particles

(16-10-2024, 11:06 AM)vrtraining Wrote: and overdraw works fine if collision is not invoked.

(16-10-2024, 11:51 AM)josemendez Wrote: 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.

(16-10-2024, 01:26 PM)vrtraining Wrote: 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.

(16-10-2024, 01:26 PM)vrtraining Wrote: I debugged and enabled disabled everything since last 2 days in project, it only happens when Obi cloth makes a collision contact.

(16-10-2024, 01:26 PM)vrtraining Wrote: Is it possible that Obi collision is causing cloth rendering to increase? that could be a reason for extended rendering?

(16-10-2024, 01:26 PM)vrtraining Wrote: Did you checked the physics part of the profiler?

(16-10-2024, 01:26 PM)vrtraining Wrote: The framerate drop and physics curves are proportional