Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Multiple obi solvers
#6
(19-01-2022, 05:18 PM)lufydad Wrote: I see another strange thing when the gameobjects are instantiated : https://imgur.com/a/kScsSBR

In the 2 cases it seems to come from the the ApplyConstraint (see https://imgur.com/a/8XIcdFG).
The interpolation costs only 3 ms, while fixed update costs 13ms.

Noticed a suspicious thing in that profiler pic:

60 (!) calls to FixedUpdate, I guess since you're using deep profiling that this is in part due to death spiral. (0.33/0.02 = 17 calls per frame at worst, times 3 player updates = 51 calls, does not quite add up but it's close).

However took a closer look at your original profiler pic, and during the spike there's 42 calls to FixedUpdate, so this is definitely not caused by deep profiling. Seems like your simulation starts and immediately enters a downwards spiral, then it recovers from it shortly after.

Things that might cause this:

- Maybe you're using async compilation in Burst? This will lazily compile your jobs on the fly the first time they're executed, during gameplay. The result is that the first few frames of anything that uses Burst are a lot slower since A) it's not actually using Burst yet B) code is being compiled in the background as the game runs. This only happens in-editor (standalone is precompiled at build time) and can be optionally disabled so all Burst code is compiled when you press play. From the manual:

http://obi.virtualmethodstudio.com/manua...kends.html

Quote:keep in mind that Burst uses asynchronous compilation in the editor by default. This means that the first few frames of simulation will be noticeably slower, as Burst is still compiling jobs while the scene runs. You can enable synchronous compilation in the Jobs->Burst menu, this will force Burst to compile all jobs before entering play mode.

- Instantiating objects in the solver does have some overhead, as particle data must be converted from actor to solver space and constraint batches from different actors merged. Maybe this extra overhead is enough to tip performance over the edge of the spiral? Does this happen with fewer actors (ropes) in your scene?

Don't know if I'm on the right track here, the spiral is always just a symptom of other issues but these seem like the most plausible to me. Let me know how it goes!
Reply


Messages In This Thread
Multiple obi solvers - by lufydad - 17-01-2022, 10:42 AM
RE: Multiple obi solvers - by josemendez - 17-01-2022, 11:01 AM
RE: Multiple obi solvers - by lufydad - 17-01-2022, 03:21 PM
RE: Multiple obi solvers - by josemendez - 17-01-2022, 08:14 PM
RE: Multiple obi solvers - by lufydad - 19-01-2022, 05:18 PM
RE: Multiple obi solvers - by josemendez - 20-01-2022, 11:00 AM
RE: Multiple obi solvers - by lufydad - 21-01-2022, 03:50 PM
RE: Multiple obi solvers - by josemendez - 21-01-2022, 03:57 PM
RE: Multiple obi solvers - by lufydad - 21-01-2022, 04:39 PM
RE: Multiple obi solvers - by josemendez - 21-01-2022, 06:12 PM
RE: Multiple obi solvers - by lufydad - 24-01-2022, 02:10 PM
RE: Multiple obi solvers - by josemendez - 24-01-2022, 03:05 PM
RE: Multiple obi solvers - by lufydad - 24-01-2022, 04:10 PM
RE: Multiple obi solvers - by josemendez - 25-01-2022, 09:32 AM