Does anybody else have this issue? In the documentation, it states that you can set Application.backgroundLoadingPriority to limit specifically the time spent on integration (integrating the loaded asset onto the main thread) to improve gameplay performance while loading, however, that does not seem to be the case in my testing (specifically against loading Addressables with the Addressable System).
I’ve already verified that it is setting the backgroundLoadingPriority, but it doesn’t seem to take any effect on loading Addressables.
Does anybody else see this behaviour? Is this an oversight somewhere on my part or is this a bug that I should report?
[You may also notice that my EarlyUpdate.XRUpdate consistently takes a stupid amount of time, that is related to another bug ticket that’s been corroborated by a number of developers ~ see here but that is unrelated to the Addressable bug]
After speaking with the team, looks like this could be a bug. Could you file a bug report for us so that we can dig into it further? Unity QA: Building quality with passion
@cassius Sorry, I haven’t filed a bug report yet, I got lured down into a rabbit hole with AWS and their .NET SDK. Last I tested though, I still had the same problem, so I’ll try to file a bug report today
Apologies for being slower than a hooker on Tuesday night. I’m a college student who just finished up finals (one more semester to go then I’m DONE).
I’ve submitted the bug report, and will touch back here as I receive updates. So far, I’ve been able to replicate this bug in virtually all scenarios. I’ve tested it against a variety of Unity versions (subsets of Unity 2020.1), and they all had the problem, as well as a variety of Addressable System versions (between 1.15.1 and 1.16.15), and they all had the problem.
I noticed that if you change the Addressable System’s mode in the editor from “Use AssetDatabase” and “Use Existing Build”, the latency stays roughly the same, however it is attributed to different things. In “Use AssetDatabase”, it is attributed to a File.Read() call in “AsyncReadManager.SyncRequest”, while if you’re emulating an actual build (as well as what I saw when I profiled an actual build), it shows “Application.Integrate Assets In Background”, so I still feel confident that it is related to Application.backgroundLoadingPriority not being obeyed.
Another thing to note, the delay/spike seen, increases with larger bundle files, and decreases with smaller bundle files. This intuitively makes sense, based on what I already assume to be the problem.
I will be making a new branch of my project on Unity 2020.2 in order to test out the new OpenXR that Unity is supporting , so I’ll be able to test against those versions as well soon.
@cassius@TreyK-47 i have received a response, they were successfully able to reproduce the bug, and have created an issue tracker. Here’s the link so you can vote on it
I think there’s some wording error in how they stated the “actual result”, so I left a comment on that.
Hi may i know is there an update to this issue? the link you’ve provided leads to a 404 page.
I am using Unity 2020.3.3f1, Addressables 1.17.17 and looks like this issue still persist?
