(20-12-2019, 10:03 AM)josemendez Wrote: Ok! Installing same Ubuntu version to test it out there. This might take a while because we need to reproduce the issue, isolate a reproducible minimal case, and wait for the guys at Eigen to provide a fix. Worst case scenario, we can temporarily disable alignment (and vectorization) to get it to run, although with much worse performance.

(20-12-2019, 11:09 AM)Emmaa Wrote: I would like to disable to disable alignment (and vectorization) to get it to run if possible how much time do you think the proper fix would take? (ballpark estimation)

(20-12-2019, 01:46 PM)josemendez Wrote: Think I found the cause and fixed it, no need to resort to disabling vectorization. I've sent the patched libs to your colleague (Alexander) via email. Let me know how it goes so that I can include the fix in the next production release.

Thanks for reporting this!

(20-12-2019, 03:05 PM)Emmaa Wrote: Thank you soo much! working perfectly on our side!

(09-05-2020, 03:00 PM)Эммаа Wrote: Hi! We are experiencing the Dll not found execption in the linux editor and linux build (again), but this time, everything works, but the performance is way worse than on windows.

The issue is: In windows we are getting 60+ fps all the time (around 80) and on a very similar machine, (same CPU) we are getting less than 30.

I'm not sure exactly what is causing this, if you could help us figure out the issue this would be amazing!

Here's the details:

unity version: 2019.3.7f1
Obi version: the one you sent us by mail (5.1?)
Linux distribution used in the editor: ubuntu 18.04 LTS
Linux distribution used in production (build): Debian 8

number of particles used: 810 (2 softbodies)
substep: 1
constraints iterations: Collision, shape matching and pin: 3 everything else disabled
Fixed Timestep: 0.02
Maximum allowed Timestep: 0.1

While profiling on windows we had an Obi (fixed update) of 2.15 ms which is great and fits perfetcly what we allowed in terms of CPU time for the softbody;

But in linux it's another story, we are getting around 117 ms for it; here are some screenshots of the profiler in linux:

Overview:



Other observation: Commenting out interpolation from the update method in  solves the issue, but softbody stops reacting (obisolver.cs:1339)

---

Second post for more screenshots:

ObiUpdater.EndStep()



ObiUpdater.BeginStep()



ObiUpdater.Substep()



thanks in advance!

(09-05-2020, 03:26 PM)IlyaZzz Wrote: Hello, I also have this problem (When I build linux build on Windows and it has performance in two-three times less than Windows). 
Have you tried to build in il2cpp mode? 
And do you have this issue: http://obi.virtualmethodstudio.com/forum/showthread.php?tid=1176&pid=6703#pid6703 ?
How do you resolve problem with Oni dll in Linux Editor?

Quote:Hello, I also have this problem (When I build linux build on Windows and it has performance in two-three times less than Windows). 
Have you tried to build in il2cpp mode? 

Quote:And do you have this issue: http://obi.virtualmethodstudio.com/forum...03#pid6703 ?

Quote:How do you resolve problem with Oni dll in Linux Editor?

Quote:Hi,

There's a slight difference in performance between both libraries, mainly because the windows one is compiled using llvm/clang while the linux one uses MingGW.

This alone does not justify such large performance drops as the one originally reported (2 ms - 117 ms) so the only cause I can think of is death spiraling. In the OP's profiler pics, it is clearly visible that FixedUpdate is being called 6 times per frame. That alone will cause performance to be 6 times slower, as physics should only be updated once per frame under normal circumstances. Increasing Unity's fixed timestep or decreasing the max fixed timestep would enable the simulation to recover and perform normally.