Help ObiSolver.Lateupdate() bad performance

[josemendez]

 
Hi Again,
What's the status of this? I ask because I can confirm that the rope rendering (extruder or line-renderer) is still the MOST heavy operations of running ropes on mobile devices (we're upgraded to oculus quest 2 but having hard times with ~300 particles and just the line renderer. I can run roughly twice as many particles when not using any rope renderers.

The Burst-based backend has been available for quite a while now, since 5.6 it's the default backend. Will run faster on most mobile devices including Quest:
http://obi.virtualmethodstudio.com/manua...kends.html

Note you need to install the required package dependencies for it to run. Otherwise Obi will fallback to the native backend.

Also, I noticed significantly lower performance when building with IL2CPP over Mono.
200 particles on two ropes with a line renderer and full smoothing runs around 72 fps on the Quest 2 with Mono, but 31 fps with IL2CPP ARM64.
Any apparent reasons for this?

Most probably death spiraling. If IL2CPP is even slightly slower than Mono, it can trigger multiple FixedUpdate() calls per frame which will cause performance to plummet. Profiling will give definite answers in this case.

As a last question, it looks like we used to be able to make bending constraints at start/ends of ropes;

https://youtu.be/pe5mROQqPv8?t=86

I would like to mimic this behavior for particle attachments and/or stitches.

It still works the same way as always: attach/stitch two particles instead of just one.
The principle is the same: one particle is a point and as such, it will rotate freely. Two particles define a straight line, so they can constrain orientation.