I filed a bug, but maybe I’m missing something. Where does the downloaded asset “go” when it has been retrieved in the WebGL player? Can’t I just request again, and let the browser cache deal with it? It appears that Addressables incorrectly does not ask for it again, due to probably a broken interaction with its internal representation of cached assets.
Also, it isn’t at all obvious what the RemoteLoadPath should be.
I just wound up disabling everything and going back to like, having the stuff in my scene like before. It just doesn’t seem to work with WebGL and I think the people here reporting that it does haven’t done the work to prove to themselves they aren’t accidentally shipping their assets in their scene anyway.
Hey just wondering on this one was - i am getting could not allocate memory and i use the DownloadDependenciesAsync - is it loaded it into memory and uncompressed or something?- cause i figured it should be downloading the asset pack to a file and then when loadassetasync is called then it will look in that file and load that file…my build is like 24M and my memory goes to 3G+ just from downloading my assets ( which is about 500M in total each asset pack). seems to happen specifically near the end of the cutscene asset pack download - which is 280M of mp4s (3 in total), the other large asset pack is the animator asset pack which contains the animator controllers and the anims…which is about 160M…and that seems to jumps in memory too
well maybe it needs to release like i see in the docs because false is the default but I get an error when i try that
stating - “attempting to use an invalid operation handle” - does this look right? - figure it should be :
its completed. do what i need to verified that it is completed and then release.
var loadOperation = Addressables.DownloadDependenciesAsync(LabelsToDownload*);* asyncoperations.Add(LabelsToDownload*.labelString, loadOperation);* StartCoroutine(LoadProgress(loadOperation, i)); loadOperation.Completed += LoadComplete; private void LoadComplete(AsyncOperationHandle inOperation) { if (inOperation.Status == AsyncOperationStatus.Succeeded) { foreach (var patcher in PatcherUI) { foreach (var a in asyncoperations) if (patcher.AssetTagName == a.Key && inOperation.Result == a.Value.Result) { patcher.SetProgress(inOperation.PercentComplete); patcher.SetStateLabel(string.Format(“Download Completed {0}”, a.Key)); Debug.Log("completed " + a.Key); TotalAssetPacksCompleted++; } } Debug.Log("Releasing handle from " + inOperation.DebugName); Addressables.Release(inOperation);
so still working through this …I was having issues with it compiling with the above code but with autorelease true it was able to but the issue with autorelease is as per the docs - the status cannot be retrieved …so i worked around it and tweaked it…seems to work better - as far as the memory issues though…still there…the cutscenes asset pack still tries to rise passed 3G+ even though its only 200MB in size…as far as i can tell anyways…if i remove that pack from the build it doesnt do that and loads the next scene…tried to update to 1.16.6 from 1.8.5 and now i am getting 404 errors so now dealing with that. I dont see any differences in workflow as far as i can tell between the versions in the change log so i am guessing its the same - new build default script > then build the game…Trying to purge the build cache and will try again…failing that relaunch of unity sometimes fixed funky stuff.
alrighty after updating the addressables it seems to have issues downloading my scene asset pack - least i narrowed it down - gonna try to rebuild the pack from scratch
ya alrighty - so none of that worked - reverted back to 1.8.5 - that resolved the issue again - guess something in the newer versions causes an issue with scene addressable assets
@unity_bill Is the issue already resolved?
Still seeing this error.
Unity 2019.4.12f1
Addressables 1.16.15
When the asset is re-requested, the game freezes forever. If you disable the cache in groups, everything works. This is only in webgl. In android and ios it works with the cache enabled.
Hm, honestly I’m not sure what happened with this one. I know we’re looking into some WebGL issues right now so I’ll pass this along. I’ll go ahead and make another ticket on our end to look at this.
I know there are issues with AssetBundle caching issues that are somehow caused by a browsers caching. That may be what happened, actually. We might have passed this along to the WebGL team to look at. It might be worth checking the WebGL forums.
I’ll make another ticket on our end to check this out just in case.
Hi everyone, by any chance are your AssetBundles using LZMA compression? On WebGL, LZMA compressed bundles load inefficiently with the cache enabled. Instead you can use LZ4 compression.
Hi everyone, I also met this issue.
I am using Unity 2020.3.2f, Addressables 1.16.19.
I want to say, that unity_bill’s advice helped. Disabling asset bundle caching (done on the per-group settings) prevents unity webGL from stopping when page reloads.
In addition I think it is imporant to mention, that
Caching groups does not work for WebGL, although it normally works for pc build.
Also, when caching is enabled for webGL, I can normally download some minor files, and reload pages working fine. The problem occurs when I want to dowload many or large files.
Maybe this information will help to solve this issue.
Or, is it already solved in newer versions?
p.s.The following information is not related to this issue, but it can save you lots of time, finding the solution. !Do not use local python http server for testing addressables. It works fine with small files, but stucks every time, when large file is required. I recommed using google cloud or other cloud solution for downloading/testing adressable assets in large projects.
Hmm I know that there’s an incoming issue regarding memory usage spiking when using AssetBundle caching on chromium browsers (Chrome, Edge, Vivaldi). Does using FireFox instead help?