Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Help  Performance issues
#21
(10-12-2019, 12:15 PM)Wattosan Wrote: Hey,

I reduced the max particle count to 600 for the solver but this did not have any notable effect. Used particle count is 165 (noticed this information inside the Solver's inspector.

Sometimes ObiSolver.LateUpdate() and ObiSolver.FixedUpdate() taken up roughly the same amount of time (4ms each) but most of the time LateUpdate() takes around 6ms and FixedUpdate() 2ms.

What should the ms stay at? Doesn't this depend on little bit on the hardware? CPU is 7700HQ and GPU GTX 1070, if that helps. And these measurements are taken from inside the Editor. Perhaps the calculation time is reduced in a build.

Hi,

How many constraint iterations/solver substeps are you using? 4-7 ms for a bit over a hundred particles is not normal. Should be below half a millisecond in-editor. Depends a bit on the hardware, but with a quad-core CPU it should be even faster.

Edit: I assume you're not using deep profiling?
Reply
#22
(10-12-2019, 12:28 PM)josemendez Wrote: Hi,

How many constraint iterations/solver substeps are you using? 4-7 ms for a bit over a hundred particles is not normal. Should be below half a millisecond in-editor. Depends a bit on the hardware, but with a quad-core CPU it should be even faster.

Edit: I assume you're not using deep profiling?

Hi,

I am not using deep profiling.

An example frame:
Editor loop takes 46.1% of calculations, 2 calls and 8.35 ms. Profiler takes 3% and 0.55 ms.
PlayerLoop in total takes 50.6% and 9.15 ms.
ObiSolver.LateUpdate() takes 21.1% and 3.88 ms.
FixedUpdate.ScriptRunBehaviour takes 6.8% and 1.24ms. 5.9% of 6.8% and 1.09 of 1.24 ms of this is ObiSolver.FixedUpdate().
These two are also the highest performance demanding operation.
Next is FixedUpdate.PhysicsFixedUpdate with 4.7% and 0.87 ms. This has quite a lot of sub calculations with the maximum taking 0.6% (0.11 ms).
Then comes Camera.Render with 3.8% and 0.69 ms.

Substeps property of the solver is set to 1. Every constraint calculation in the solver is active and for each constraint solver the Iteration count is 3 and relaxation is 1. 

Sequential evaluation: Distance, Particle Collision, Collision, Skin, Stretch Shear Bend Twist, Chain
Parallel evaluation: Bending, Particle Friction, Friction, Volume, Shape Matching, Tether, Pin, Stitch, Density.

All rods use the following constraints: Stretch Shear, Bend Twist, Chain, Tether, Pin (there is 1-2 pins for each rod).
All ropes use the following constraints: Distance, Bending, Tether, Pin (1-2 pins for each rod).

There are 4 rods and 2 ropes.

Using Unity 2019.1.14f1.
Reply
#23
(10-12-2019, 01:16 PM)Wattosan Wrote: Hi,

I am not using deep profiling.

An example frame:
Editor loop takes 46.1% of calculations, 2 calls and 8.35 ms. Profiler takes 3% and 0.55 ms.
PlayerLoop in total takes 50.6% and 9.15 ms.
ObiSolver.LateUpdate() takes 21.1% and 3.88 ms.
FixedUpdate.ScriptRunBehaviour takes 6.8% and 1.24ms. 5.9% of 6.8% and 1.09 of 1.24 ms of this is ObiSolver.FixedUpdate().
These two are also the highest performance demanding operation.
Next is FixedUpdate.PhysicsFixedUpdate with 4.7% and 0.87 ms. This has quite a lot of sub calculations with the maximum taking 0.6% (0.11 ms).
Then comes Camera.Render with 3.8% and 0.69 ms.

Substeps property of the solver is set to 1. Every constraint calculation in the solver is active and for each constraint solver the Iteration count is 3 and relaxation is 1. 

Sequential evaluation: Distance, Particle Collision, Collision, Skin, Stretch Shear Bend Twist, Chain
Parallel evaluation: Bending, Particle Friction, Friction, Volume, Shape Matching, Tether, Pin, Stitch, Density.

All rods use the following constraints: Stretch Shear, Bend Twist, Chain, Tether, Pin (there is 1-2 pins for each rod).
All ropes use the following constraints: Distance, Bending, Tether, Pin (1-2 pins for each rod).

There are 4 rods and 2 ropes.

Using Unity 2019.1.14f1.

Ok, so the simulation takes 1.2 ms (ObiSolver.FixedUpdate) and rendering (ObiSolver.LateUpdate) 3.8 ms, right? (FixedUpdate.PhysicsFixedUpdate is Unity's physics)

That could be within normal ranges, I was under the impression that simulation alone was taking 4-7 ms.
I assume you're using the default Extruded renderer for the ropes, correct? Are you using smoothing?
Reply
#24
(10-12-2019, 01:37 PM)josemendez Wrote: Ok, so the simulation takes 1.2 ms (ObiSolver.FixedUpdate) and rendering (ObiSolver.LateUpdate) 3.8 ms, right? (FixedUpdate.PhysicsFixedUpdate is Unity's physics)

That could be within normal ranges, I was under the impression that simulation alone was taking 4-7 ms.
I assume you're using the default Extruded renderer for the ropes, correct? Are you using smoothing?

Yes, currently the ObiSolver.FixedUpdate() seems to remain between 1.2-2.5ms. LateUpdate() between 3.5-6.0 ms.

I am using the Rope Extruded Renderer for both the rods and the ropes. Smoothing for rods and ropes is set to 1.

EDIT: Okay, reducing the smoothing to 0, it is now 3 times faster. It takes around 1-2 ms for the LateUpdate() now.
Reply
#25
(10-12-2019, 02:00 PM)Wattosan Wrote: Yes, currently the ObiSolver.FixedUpdate() seems to remain between 1.2-2.5ms. LateUpdate() between 3.5-6.0 ms.

I am using the Rope Extruded Renderer for both the rods and the ropes. Smoothing for rods and ropes is set to 1.

EDIT: Okay, reducing the smoothing to 0, it is now 3 times faster. It takes around 1-2 ms for the LateUpdate() now.

Smoothing increases the amount of rope sections that have to be processed and rendered. So by decreasing it, rendering becomes cheaper.

You could also use a rope section with less segments (the default one uses 8), so that each rope section is also cheaper to compute. Maybe you can get away with 5 or even 3 segments.
Reply
#26
(10-12-2019, 02:42 PM)josemendez Wrote: Smoothing increases the amount of rope sections that have to be processed and rendered. So by decreasing it, rendering becomes cheaper.

You could also use a rope section with less segments (the default one uses 8), so that each rope section is also cheaper to compute. Maybe you can get away with 5 or even 3 segments.

How do you control the segment count? By the resolution variable? It is currently set to 0.1.
Reply
#27
(10-12-2019, 03:43 PM)Wattosan Wrote: How do you control the segment count? By the resolution variable? It is currently set to 0.1.

Resolution controls the amount of particles (which is equal to the amount of sections when smoothing == 0).

Each section has multiple segments. The renderer takes a "section" asset as parameter. The DefaultSection is used by default, you can create your own rope sections by right clicking in the project folder->Create->Obi->Rope Section. Select it, and in its inspector you can change the shape of the section as well as the amount of segments.

If you've ever extruded a shape along a path in any 3D modeling software, think of the section as the shape that is extruded, and the rope as the path it is extruded along.
Reply
#28
To add to this thread:

When I toggle off the obi solvers (I have 4 ropes each with a solver component), then the performance increase is massive. In the oculus quest it can only run one rope+solver.

   


Some of the discussion prior to this is hard to follow. Such as one user saying reducing smoothing improves their issue, but I don't see that option any where. If you could provide some screen shots with your reply or exact public member names + script that would greatly appreciated. Attached is my rope setup currently. *Note: I tried the line renderer version and it did not improve anything.

[attachment=530]     [attachment=532]    
Reply
#29
(10-12-2019, 05:25 PM)BisuDagger Wrote: To add to this thread:

When I toggle off the obi solvers (I have 4 ropes each with a solver component), then the performance increase is massive. In the oculus quest it can only run one rope+solver.




Some of the discussion prior to this is hard to follow. Such as one user saying reducing smoothing improves their issue, but I don't see that option any where. If you could provide some screen shots with your reply or exact public member names + script that would greatly appreciated. Attached is my rope setup currently. *Note: I tried the line renderer version and it did not improve anything.

You have 100 (!) distance and friction iterations, that's enough of a reason to get awful performance. Why do you need that many iterations?

Btw, "smoothing" can be found in the ObiRope component inspector (in Obi v4). It's clearly visible in the screenshot you posted.
Reply
#30
(10-12-2019, 05:39 PM)josemendez Wrote: You have 100 (!) distance and friction iterations, that's enough of a reason to get awful performance. Why do you need that many iterations?

Btw, "smoothing" can be found in the ObiRope component inspector (in Obi v4). It's clearly visible in the screenshot you posted.





IIRC, because of the long length of the rope and load attached to it, the load was springy and didn't have a smooth movement when I used cursor.ChangeLength("using a value between 0 and 1").

   

I fixed the rope components and was able to run all 4 solvers on the Oculus Quest. The result unfortunately is in the movement. The position of the Load and Rope is update and then the rope stretches downward some giving the load a bouncy movement. What attribute can I use to reduce the stretching of the rope? I need to be able to treat this rope more like a chain where there is very little stretching and the length of the rope should be within inches of what I tell it to be.
Reply