Help ObiSolver.Lateupdate() bad performance

Help ObiSolver.Lateupdate() bad performance - Printable Version

+- Obi Official Forum (https://obi.virtualmethodstudio.com/forum)
+-- Forum: Obi Users Category (https://obi.virtualmethodstudio.com/forum/forum-1.html)
+--- Forum: Obi Rope (https://obi.virtualmethodstudio.com/forum/forum-4.html)
+--- Thread: Help ObiSolver.Lateupdate() bad performance (/thread-1562.html)

Pages: 1 2 3

RE: ObiSolver.Lateupdate() bad performance - josemendez - 05-08-2021

(04-08-2021, 04:07 PM)TheMunk Wrote:
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/manual/6.2/backends.html

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

(04-08-2021, 04:07 PM)TheMunk Wrote: 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.

(04-08-2021, 04:07 PM)TheMunk Wrote: 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.

RE: ObiSolver.Lateupdate() bad performance - TheMunk - 05-08-2021

(05-08-2021, 08:39 AM)josemendez Wrote: 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/manual/6.2/backends.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.

Quote: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.

Quote: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:
[Image: stitch1.png]

If I add this green stitch it goes crazy as those two points are stitched together;
[Image: stitch2.png]

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?

RE: ObiSolver.Lateupdate() bad performance - josemendez - 05-08-2021

(05-08-2021, 09:55 AM)TheMunk Wrote: 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/manual/6.2/roperenderingmodes.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.

(05-08-2021, 09:55 AM)TheMunk Wrote: 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.

RE: ObiSolver.Lateupdate() bad performance - TheMunk - 05-08-2021

(05-08-2021, 10:01 AM)josemendez Wrote: 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.

RE: ObiSolver.Lateupdate() bad performance - josemendez - 05-08-2021

(05-08-2021, 10:04 AM)TheMunk Wrote: 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.

RE: ObiSolver.Lateupdate() bad performance - TheMunk - 16-08-2021

(05-08-2021, 10:01 AM)josemendez Wrote: 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.

RE: ObiSolver.Lateupdate() bad performance - josemendez - 16-08-2021

(16-08-2021, 09:59 AM)TheMunk Wrote: 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.

RE: ObiSolver.Lateupdate() bad performance - TheMunk - 16-08-2021

(16-08-2021, 10:10 AM)josemendez Wrote: 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?

RE: ObiSolver.Lateupdate() bad performance - josemendez - 16-08-2021

(16-08-2021, 10:13 AM)TheMunk Wrote: 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?

RE: ObiSolver.Lateupdate() bad performance - TheMunk - 16-08-2021

(16-08-2021, 10:15 AM)josemendez Wrote: What do you mean by "end loop"? Like a knot of some kind, or a lasso?

Yea like a lasso