29-07-2021, 12:08 PM
(This post was last modified: 29-07-2021, 12:26 PM by 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.
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).
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.
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.
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.
Quote: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).
Quote: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.
Quote: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.