Help ObiSolver.Lateupdate() bad performance

[josemendez]

So I've been reading a lot up on the forums here regarding optimizing ropes and most of the time the issue is death spiraling with the fixed update - however my issue seems to be the rope extruder taking up a lot of CPU time. Specifically 7 ms. Turning off the extruder individually on the ropes gives me the performance back.

Main issue: 
Obisolver.LateUpdate() taking 7 ms cpu time. 


Rope Info:
3 ropes
~200 particles in total
simulated on fixed Update.
2 substeps
Standard contraints simulations (3 iterations, 1 relaxation)
A few handles and a few colliders (less than 10) most static.
Extruder is using a 4 segment section

Time settings:
Fixed timestep: 0.01388889 (Oculus Quest)
Max: 0.0139

Solutions tried:
Using the linerenderer, but lost almost the same amount of performance gained from obisolver.lateupdate() to camera.FireOnPreCull(). (EDIT: seems to be the UpdateRenderer on the line renderer)
Turning smoothing down to 0 - seems to give around 1,5 ms for a single rope. Having all on 0 smoothing and 0,2 resolution yields 5,4 ms of obiSolver.Lateupdate()


System info:
CPU: AMD Ryzen 5 1600 Six-core processor
CPU: GTX 1070





Is this expected performance or am I missing something?


Edit:
Tried creating a new scene and making 3 ropes, all with 0 smoothing, default 8-section rope-section, one with .5 resolution, one with .3 and one with .2.
All 3 ropes on same solver: total particles 285
Getting around 3,8 ms on obisolver.lateupdate(). - why is there such a big difference?

EDIT 2:
Also, out of general curiosity, which is better for performance? high smoothing or high resolution? and how dependent on the renderer is either?

What version are you using? Obi 4.X or 5.X?

Rope resolution determines the amount of particles in your rope. Together with smoothing, this allows you to decouple simulation quality from rendering quality.

At the end of every frame, each particle is used as a control point for a bézier spline (generated using an extremely optimized version of the Chaikin corner-cutting algorithm). This algorithm outputs multiple curve points, depending on the smoothing parameter. At 0 smoothing, one point is created for each particle. As you increase smoothing, additional points in-between particles are added.

The renderer takes all these points as input and generates a mesh by placing a rope section at each point, generating vertices for each one, and stitching them together with triangles.

So the amount of points outputted after rope smoothing is what largely determines the renderer's performance. The amount of particles in the rope is the amount of points generated at 0 smoothing, and increases with higher smoothing values.

What's better for performance depends a lot on your needs. The rule of thumb is to use as few particles as you can get away with, then increase smoothing if rendering is too "blocky". You should almost never need smoothing > 0 if the rope has high resolution.