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.

[TheMunk]

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.

I'm already using burst - I was talking about the vertex calculations for creating the extrusion/line renderer.

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.

If that's the case I guess I could increase the fixed timestep and see a performance increase, which is not the case. 
Increasing fixed and max timestep from 0.0138 to 0.0333 only increased fps by 5~10 frames. 

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.

I don't quite get that. I stitch two like this and I just get the free rotation:

If I add this green stitch it goes crazy as those two points are stitched together;

Similar result if I stitch particle (from top to bottom) 1 to 3, and 2 to 4.

What exactly am I supposed to be stitching to get a (seemingly) continuous rope made of multiple rope segments?

[josemendez]

I'm already using burst - I was talking about the vertex calculations for creating the extrusion/line renderer.

Oh, ok. That is scheduled for Obi 7, as it involves taking all rendering code and moving it to Burst too, which is a lot of work. Will take a few months to get there. In the meantime, there's ways to make rendering faster depending on what your use case is.

If your ropes have a significant amount of straight regions, using decimation can improve performance a lot. This will adaptively reduce mesh resolution based on curvature. See:
http://obi.virtualmethodstudio.com/manua...modes.html


For instance if you ropes cannot be torn or resized, skinning a mesh to the particles will be much faster because no mesh data needs to be calculated from scratch every frame. This will require you writing some custom code to copy particle positions to bones though.

What exactly am I supposed to be stitching to get a (seemingly) continuous rope made of multiple rope segments?

When you stitch two particles together, they will try and collapse into a point. Stitching the way you currently are is guaranteed to cause a mess.
Overlap the ropes and then stitch them, just like you'd do in real life to sew two ropes together:

Code:

   
          (o)--------(o)---------(o)
           !          !
(o)-------(o)--------(o)

The "!" are stitches, (o) are particles and ------ rope segments. Hope my shitty diagram makes some sense, let me know otherwise.
Don't forget to deactivate collisions between the stitched particles, otherwise they will try and collide with each other.

[TheMunk]

When you stitch two particles together, they will try and collapse into a point. Stitching the way you currently are is guaranteed to cause a mess.
Overlap the ropes and then stitch them, just like you'd do in real life to sew two ropes together:

Code:

   
          (o)--------(o)---------(o)
           !          !
(o)-------(o)--------(o)

The "!" are stitches, (o) are particles and ------ rope segments. Hope my shitty diagram makes some sense, let me know otherwise.
Don't forget to deactivate collisions between the stitched particles, otherwise they will try and collide with each other.

Thanks, think i got it!


Also figured out the IL2CPP performance issue apparently was because i was using "debug" compiler configuration - which normally is not an issue, but may have big implications for Obi.

[josemendez]

Thanks, think i got it!


Also figured out the IL2CPP performance issue apparently was because i was using "debug" compiler configuration - which normally is not an issue, but may have big implications for Obi.

"debug" compiling is always a lot slower, since it skips code optimizations. This is not a big deal for simple stuff, but as soon as you have performance-sensitive code this can become huge.

Edit: same applies to deep profiling, since it adds timing markers to every function call making the code significantly slower. This happens at compile time. A common pitfall is making a build with "deep profiling support" enabled, but assuming it will run fast as long as you don't connect the profiler and enable "deep profiling". Since the markers are introduced when compiling the code, the resulting build will be slow regardless of using deep profiling or not.

[TheMunk]

Don't forget to deactivate collisions between the stitched particles, otherwise they will try and collide with each other.

Hello again, I can't seem to disable collision between particles.
I'm stitching together a loop at the end of a rope (like a lasso), but even with all particles set to category 1 and collision to "nothing" the stitched particles still collide when "self collisions" is turned on.

[josemendez]

Hello again, I can't seem to disable collision between particles.
I'm stitching together a loop at the end of a rope (like a lasso), but even with all particles set to category 1 and collision to "nothing" the stitched particles still collide when "self collisions" is turned on.

Self-collisions != collisions != inter-collisions.

Filters only control collisions and inter-collisions. Self-collisions can only be turned on or off, otherwise you'd quickly run out of categories when having a few self-colliding actors that don't have to collide with each other.

[TheMunk]

Self-collisions != collisions != inter-collisions.

Filters only control collisions and inter-collisions. Self-collisions can only be turned on or off.

So no way to achieve what I want without the en loop being a separate rope?

[josemendez]

So no way to achieve what I want without the en loop being a separate rope?

What do you mean by "end loop"? Like a knot of some kind, or a lasso?

[TheMunk]

What do you mean by "end loop"? Like a knot of some kind, or a lasso?

Yea like a lasso