Obi Official Forum

Full Version: obi fluid unusable since 2021.2.17f1
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Unity must have changed something that made it incompatible with Obi in 2021.2.17f1 that unfortunately made it into the 2021.3 LTS version, which I really would like to use.

The editor is unusable as soon as you import Obi Fluid into the project, everything slows down to a crawl. Going into play mode in any of the sample scene will result in around 5-10 FPS, and even just navigating the scene view outside of play mod is unusably slow.



This affects the entire project, not just the scenes that have Obi components in them. The problem is the exact same even in a completely new, empty scene in a project that has Obi Fluid imported.



There are no errors being reported in the console, so I'm not sure what is actually going on. But it's definitely Obi that is causing the problem, I tried it multiple times on completely blank projects and each one of them became unusable immediately after importing Obi. I also tried saying yes and no the the script upgrade prompt, it does not make a difference. Closing the project in this state will also crash the editor pretty much every time, here is the log in case that helps:

https://we.tl/t-kSM2qyMyxs (Too big for this post and pastebin)
Hi there!

I'm developing using 2021.2.19, and had no problems of any sort with Obi Fluid (or any other Obi asset). No other reports similar to yours either, this sounds really strange. Obi does no work if there's no components in the scene, it doesn't attach itself to editor initialization callbacks or anything similar.

The stack trace in the crash log you provided doesn't contain anything related to Obi, these are the last few lines:

Quote:0x00007FFA852BD988 (mono-2.0-bdwgc) [C:\build\output\Unity-Technologies\mono\mono\mini\mini-runtime.c:3286] mono_jit_runtime_invoke
0x00007FFA851FE744 (mono-2.0-bdwgc) [C:\build\output\Unity-Technologies\mono\mono\metadata\object.c:3066] do_runtime_invoke
0x00007FFA851FE8DC (mono-2.0-bdwgc) [C:\build\output\Unity-Technologies\mono\mono\metadata\object.c:3113] mono_runtime_invoke
0x00007FF7E0AAECF4 (Unity) scripting_method_invoke
0x00007FF7E0AA9914 (Unity) ScriptingInvocation::Invoke
0x00007FF7E0AA325A (Unity) ScriptingInvocation::Invoke<bool>
0x00007FF7E15C5988 (Unity) core::function<bool __cdecl(void)>:Gran sonrisaispatchT<<lambda_0e5811cec38eff5093b6e5836fe870c8> >:Gran sonrisaispatch
0x00007FF7E15C4F6F (Unity) Editor:Lenguarogress:LenguarogressManager::CancelOperation
0x00007FF7E15E5B38 (Unity) Editor:Lenguarogress:LenguarogressManager::Shutdown
0x00007FF7E169FB22 (Unity) Application::CoreShutdown
0x00007FF7E16B23EB (Unity) Application::Terminate

Some questions that I think could help investigate this:
- Could you share a screenshot of your profiler with editor profiling enabled? This way we can see what's dragging the editor down.
- Do you have Burst installed? (maybe there's some incompatibility between Unity/Burst versions?)
Here's the profiler: https://imgur.com/a/WnXjdUS


It's all coming from EditorApplication.Internal_InvokeTickEvents() if I understand this correctly.



I tried it with and without Burst installed already, does not make any difference. I'm not using Burst anyways since it doesn't work at all, I'm also getting the index out of range error that has been reported here by several users. I would have also tried different versions but it looks like only 1.6.5 is available in the newer 2021 releases.
(19-04-2022, 09:06 AM)locque Wrote: [ -> ]Here's the profiler: https://imgur.com/a/WnXjdUS


It's all coming from EditorApplication.Internal_InvokeTickEvents() if I understand this correctly.

Would it be possible for you to enable deep profiling, to see deeper into the call stack beneath Internal_InvokeTickEvents?
I'm specially interested in the timeline view's main thread, btw (the pyramid graph at the bottom).
(19-04-2022, 09:14 AM)josemendez Wrote: [ -> ]Would it be possible for you to enable deep profiling, to see deeper into the call stack beneath Internal_InvokeTickEvents?
I'm specially interested in the timeline view's main thread, btw (the pyramid graph at the bottom).

Is this enough? https://imgur.com/a/WDGlR51

I would upload the raw profiling data, but its 12GB and I don't know how to export for a single frame.
(19-04-2022, 10:01 AM)locque Wrote: [ -> ]Is this enough? https://imgur.com/a/WDGlR51

There seems to be an inordinate amount of calls to some function right below BaseAsyncIEnumerableHandler.FetchSome() (the continuous blue rectangles below it) it would help to see what those are (just zoom in closer).

Thanks for helping me figure this out! These calls aren't part of or triggered by Obi, so far it looks completely unrelated tbh but I cannot be sure until we understand the core issue.

(19-04-2022, 10:01 AM)locque Wrote: [ -> ]I would upload the raw profiling data, but its 12GB and I don't know how to export for a single frame.

If you hit "clear", then pause profiling almost immediately, it should result in a much smaller file as it would contain just a handful frames. Having access to the profiling data would certainly be most helpful.
(19-04-2022, 10:32 AM)josemendez Wrote: [ -> ]There seems to be an inordinate amount of calls to some function right below BaseAsyncIEnumerableHandler.FetchSome() (the continuous blue rectangles below it) it would help to see what those are (just zoom in closer).

Thanks for helping me figure this out! These calls aren't part of or triggered by Obi, so far it looks completely unrelated tbh but I cannot be sure until we understand the core issue.


If you hit "clear", then pause profiling almost immediately, it should result in a much smaller file as it would contain just a handful frames. Having access to the profiling data would certainly be most helpful.

Okay, thanks for the tip. Here is the profiling data for just two frames: https://we.tl/t-4Dl1UYOde0
(19-04-2022, 10:38 AM)locque Wrote: [ -> ]Okay, thanks for the tip. Here is the profiling data for just two frames: https://we.tl/t-4Dl1UYOde0

Hi,

This is definitely a bug in Unity, unrelated to Obi. Here's what the profiler info shows:
[Image: L0DcbxO.png]

Seems like the editor is performing some kind of search trough +20000 elements every frame, which takes roughly 50 ms/frame. That's what's slowing the editor down.

I've tried reproducing this to no avail on 3 different computers (Windows 10 x2 and Mac OS 10.15.4), all using Unity 2021.3.0f1 and Obi Fluid 6.4. Both backends work and perform normally, editor performance is unaffected.

I would raise a bug report with Unity, to see if they're able to help.
Thanks for your effort once again, I reported the bug and willl try to get some help on the unity forums.

I wonder why I keep having so many unreproducable issues with Obi. I tried importing most of my other assets in 2021.3, none of them cause this issue. It's only Obi, any idea what could be different about your asset that triggers this problem?

Okay nevermind all that, I guess I wasn't thorough enough with my experiments or whatever triggers the bug is highly inconsistent.

I tried creating some more empty projects and importing Obi, and this time saying yes to converting the APIs prevented the issue. Not only that, but I can now actually use Burst for the first time since upgrading from 2019.4! All 2020 and 2021 versions prior to 2021.2.17f had the same index out of range problem, independent of whether or not I chose to upgrade the APIs.
(20-04-2022, 08:24 AM)locque Wrote: [ -> ]I wonder why I keep having so many unreproducable issues with Obi. I tried importing most of my other assets in 2021.3, none of them cause this issue. It's only Obi, any idea what could be different about your asset that triggers this problem?

No idea, Obi is just a collection of regular C# scripts and sample materials, scenes, textures, etc. It does not do anything at editor initialization, does not attach itself to editor callbacks, or anything else that could explain such a huge performance drop in-editor, with no Obi scripts being executed or even present in the scene.

The profiler clearly shows the editor is stuck doing a lot of work every frame that's completely unrelated to Obi. When it crashes, the stack trace does not contain any remotely Obi-related calls.

I'm going to speculate a bit here: Unity 2021.2.17f1 introduced a fairly large amount of changes/fixes related to the editor's search engine.
https://unity3d.com/es/unity/whats-new/2021.2.17

Quote:- Scripting: Optimized searching for scripts when the assembly name is not supplied, can significantly improve performance entering PlayMode amongst other areas.
- Search: Many UI and UX search improvements
- Search: Fixed a search indexer get document lock issue while incremental updating.
- Search: Fixed an issue where search engines initialization was not delayed until after user code was compiled
- Editor: Fixed a missing search result refresh when executing CTRL+Z to undo last block modifications
- Editor: Use SearchViewState.group to initialize initial results tab when a new search window is created.

Since the editor is going trough 20000 items every frame calling a function named "SearchEnumerator", if I had to take a wild guess I'd say the editor is stuck either building a search index for all assets in the project, or looking trough all of them, every frame.

Why does Obi trigger this? maybe because of the amount of files/assets it imports? maybe because Unity doesn't like the name or location of a specific file? I can't possibly know.
Pages: 1 2