Help Performance optimization help

[Alberos]

Hello,

I'm using Obi robe in my VR project to simulate rubber hoses of a piece of medical equipment. The target platform is Oculus Quest 2. In the app, player need to grab various part of the hose and put it in the pre-defined spot (nearby) in the scene or sometimes grab the end/start of the hose and connect it to something.

In the first phase it required 1 rope with a lot of attachments, 17 to be exact, 16 of them are static and the other one is dynamic. I try to play around with all setting and get a passable framerate at the end using guidelines from Obi Rope documentation. Now that the next phase requires around 5-6 ropes with possibly 5-10 attachment points each makes me very worry since in the first phase I barely hit 72 FPS target of the headset. So my questions are

1. Are there any more place/setting that I can tweak or change to increase performance without sacrificing too much simulation quality? (I try lower things more but the sim quality became too bad so I put it back to where it is now)
2. Right now I'm using 2 static attachment points for 1 "thing" that attached and oriented "along" the rope (one on top and another one at bottom of the "thing" to orient it). Is there a way that I can use only 1 attachment point and have it still oriented correctly?
3. If nothing I can tweak/change to improve performance, can I bake rope into mesh at runtime? As far as I know, it can only be done in edit mode. Or maybe I should have 1 solver for each rope and only turn the solver on when I need it. (Since player never have to interact with more than 1 rope at any given time anyway)

Below are relevant settings of the 1 rope in 1st phase that I settled on:


There are also some ObiColliders in the scene (around 10 + attachment points, 1 of them is a mesh collider with 384 tris, the rest are all unity's primitive)

Sorry if I sound desperate, I really am. Any help is appreciated.
Thanks.

[josemendez]

Hi there,

There's a warning in your Solver component that tells you you're using the fallback backend (Oni) because there's missing package dependencies. This performs worse on mobile platforms (which Quest is) so I'd install the Burst dependencies right away. See: http://obi.virtualmethodstudio.com/manua...kends.html

I notice your blueprint's thickness is 0.0022. That's extremely thin, and will result in a lot of particles being generated, making the simulation very expensive. How many particles are in use by your solver? This appears at the top of the solver inspector, but it's not visible in your pic.

Regarding performance tweaking, one word: profile. It's pretty much impossible for anyone (you, or me) to tell what might be the best way to improve performance with no information on what is time being spent on. Use the profiler to see what's the most expensive thing in your scene, then focus on reducing the time it takes to do that.

Normally, a single reasonably short rope shouldn't take more than 0.2-0.4 ms to simulate, that should not bring you down to 72 fps so there must be a problem somewhere.

1. Are there any more place/setting that I can tweak or change to increase performance without sacrificing too much simulation quality?

You could reduce the amount of substeps in the ObiFixedUpdater. That has the biggest impact on simulation quality vs performance.
You could use a simpler rope section (the default has 8 segments) or a simpler renderer altogether (a line renderer for instance).
You could increase your project' physics timestep (found in Unity's Time settings).

Right now I'm using 2 static attachment points for 1 "thing" that attached and oriented "along" the rope (one on top and another one at bottom of the "thing" to orient it). Is there a way that I can use only 1 attachment point and have it still oriented correctly?

Static attachments are essentially free at runtime. You could get orientation with a single attachment if using rods instead of ropes, but they're more expensive to simulate so I doubt it's worth it in your case.

3.If nothing I can tweak/change to improve performance, can I bake rope into mesh at runtime? As far as I know, it can only be done in edit mode. Or maybe I should have 1 solver for each rope and only turn the solver on when I need it. (Since player never have to interact with more than 1 rope at any given time anyway)

Simply disable the ObiRope component when you need. As long as the renderer is enabled it will still be rendered but won't be simulated.

[Alberos]

Oh that was fast.

Sorry, I already left the office for today. I will get back to you with the details tomorrow. Thanks for very fast reply.

[Alberos]

Hello again,

I'm have setup a new scene with same environment but now I duplicated that 1 rope 3 times and put it all in the same solver. Now we have 3 rope with 50 static attachment points and 1 dynamic attachment point (I changed the other 2 duplicated rope to be all static attachment). This is just to estimate how much more performance do I need when the real new phase app start developing.

First let me answer some concern that you have rise,

I notice your blueprint's thickness is 0.0022. That's extremely thin, and will result in a lot of particles being generated, making the simulation very expensive. How many particles are in use by your solver? This appears at the top of the solver inspector, but it's not visible in your pic.

I'm using it to simulate a very thin rubber hose so it has to be that thin. The solver report that for 1 rope it uses 121 particles. I'm not sure that this is too much or not. If it too much maybe I can do something about that, put the thickness up and use scale? Recommendation is always welcome, I'm very new to Obi Rope, in fact this is the first project I use the asset.

There's a warning in your Solver component that tells you you're using the fallback backend (Oni) because there's missing package dependencies. This performs worse on mobile platforms (which Quest is) so I'd install the Burst dependencies right away. See: http://obi.virtualmethodstudio.com/manua...kends.html

Well, this sounds serious, I will fix that warning first and see what the new performance look like then we can think about it after that.

Regarding performance tweaking, one word: profile.

I have run some profiling before in the past, sorry I forgot to add the profiling snapshot in, but here it is in the new scene with 3 ropes that I mentioned above:
This is running in the real device connected to Unity Profiler using USB cable.
Note that I'm using this number as a baseline now, after I fixed the backend issue I will report back the numbers again.



Both the new scene with 3 ropes and the old production one with 1 rope produce the similar result with PhysX.SolveIslandTask and ObiFixedUpdater using most of the CPU time. The 3 ropes scene take roughly 2-3x longer which kind of make sense.

Thanks

[Alberos]

Ok making warning disappear and actually use Burst improve performance by a lot. Here is the profiler after switching to Burst


Down from 28ms to 20ms CPU time.

If I rebuild the app without Development Build checked, I can hit 72FPS in 3 ropes scene without Quest CPU going at full burst (before it need CPU Level* 4, maximum level, now it only need lvl 2-3).

I might consider this as solve for now but based on this profiling result, do you have any recommendation to make it even faster? Just in case I need more dynamic attachment point (the result above only has 1 dynamic, which I might need more in the real thing)

Thanks for the help



*As far as I know, CPU Level or CPU L is a performance matrix reported by the headset, essentially, it's a CPU clock speed. The higher the level the higher the clock speed. 4 is the maximum value and 1 is the minimum.

[josemendez]

Hi!

Glad using Burst improved performance for you . There's still a couple things that could be vastly improved:

- All physics in your scene are being updated twice per frame as evidenced by the two calls to FixedUpdate (normal would be 0 to 1 updates/frame). Of each update, regular rigidbody physics are the costlier part. This is shown in orange in your profiler.

This is a direct result of your project's timestep settings. You can decrease your max allowed timestep, or increase your timestep (both found in Unity's Time settings). At the very least, this should almost double performance by bringing the amount of updates from 2 to 1.

I'd recommend reading about how physics are updated in a fixed-timestepping engine such as Unity, and its performance implications. "Death spiralling" or "Wall of despair" is a typical situation in which the cost of physics simulation exceeds rendering cost, and multiple physics steps must be taken each frame to keep physics in sync with rendering. It's what's happening in your project.

- Rope mesh generation/rendering cost seems to be quite high (4 ms). Try lowering it by reducing smoothing, increasing decimation, or using a simpler rope section. See:
http://obi.virtualmethodstudio.com/manua...modes.html

[Alberos]

Thanks for the help and recommendation, all should be OK now. I will take a look at the Physics timestep and see what I can do. I'm also using hand tracking with physics. Last time I fiddle with the time step setting the hand tracking physics freaks out all over the place. That's separate thing from Obi Rope, I will handle that myself. Anyway, thanks for the recommendation