2019.1

Strange... but what do you mean by build didn't work? the cache system didn't work or its failed to build? I am currently using 2019.1.0 with both plugins and it is working fine.

 

It would crash immediately when the wasm binary loaded. But as noted it worked for us in 2019.1.0, but not 2019.1.3.

 

Sorry for this question, but I feel like I really need to ask this.
Is sub scene streaming and entities suppose to work on latest versions of Unity when targeted WebGL?

I have tried 1 and half days of doing builds with different settings using the Unity samples project with no luck.
The project tiny is no go since its 2D based as far as I know. Everything works on editor and standalone. I haven't tested anything else.

I'm asking because I need to make a proof of concept demo for the company I'm working for and I have 3 weeks to show some cool new stuff with Unity. So far I have not been able to get any of the new ECS or addressable stuff to work with WebGL. Except multi threading seems to build up and work without the mt feature toggled on, which is quite good. Need to test toggled on at some point.

I was thinking the ability do ECS and sub scene streaming would give advantage over other engines. Add the multi threading and burst compiling and the world could be a better place.

I have been searching all place, but mostly just talk. So I'm just thinking, if I should stop wasting time on this?
I guess, if the ECS is not mentioned, then it will not be included in the WebGL build target, but then again shouldn't there be clear indication of that?? Since then its otherwise its just a waste of human resources that could be doing something useful for everyone.

Maybe a mention in the package manager in which platforms the packages are proven to work.
Thanks for anyone who can comment on this one.
Its just one cube with convert to entity script attached. On editor and standalone all fine. WebGL nothing. Not even message.



This is what I see in Firefox

 

Hi,

For WebGL, we put all our output files in the same directory. But it seems that there is an issue when you do that. The WASM file is seen as a txt/html instead of application/wasm. It is correctly configured server side, but I did notice following in the loader js:

Code (JavaScript):

1. locateFile:function(e){return"Build/".concat("build.wasm"==e?this.wasmCodeUrl:e)}}

There I see the wasm file NEEDS to be in a 'Build' directory? Is there a option if you don't want this? Can't this be changed so we can use custom names/locations?

Our game was build with 2019.2.
Thanks in advance.

 

You can change it (we overrode locateFile to simply return this.wasmCodeUrl). I agree this seemed very silly to me when I was debugging it.

 

Thanks for the idea! I ended up using this to try and get the correct directory:

Code (JavaScript):

1. locateFile:function(e){return window.location.href.replace(window.location.protocol+"//"+window.location.host,"").concat("/",this.wasmCodeUrl)}

Problem with only wasmCodeUrl was that I got

http://my.url.com/build.wasm

instead of

http://my.url.com/game/name/build.wasm

But now I get an other error:

Uncaught Error: Invalid string. Length must be a multiple of 4

UPDATE:
Nevermind, I still had my wasm file in a 'Build' directory to test the standard locateFile function.

 

It is even harder to get wasm streaming working when your files are located elsewhere and injected into the page. I think I can't even hardcode it, because where locateFile is used it will add the url of the page itself. Not the page where the file came from.

It does work with wasm streaming turned off, even without changing locateFile.
Anyone have any idea on how to do it with wasm streaming?

 

for setting webgl memory size is it enought to execute editor script like this:

Code (CSharp):

1.     [MenuItem("Assets/SetWebGLMemory")]
2.     static void SetWebGLMemory()
3.     {
4.         PlayerSettings.WebGL.linkerTarget = WebGLLinkerTarget.Wasm;
5.         //PlayerSettings.WebGL.threadsSupport = true;
6.         PlayerSettings.WebGL.memorySize = 256; // tweak this value for your project
7.     }

 

Looks like they fixed that in 2020. Gotta wait for that or look at the change they did in the UnityLoader.js and manually do the same in your output.

 

@Marco-Trivellato

There's any way to detect threading setting at runtime or compile time?

 

Is this bug resolved in any editor version as of today?

 

@JamesArndt

You still have to run it once more time to disable threading, but with false now:

Code (CSharp):

1. PlayerSettings.WebGL.threadsSupport = false;

Just deleting the editor script isn't enough.

 

Same issue trying to host off a CDN, you ever get this to work?

 

If you are reading this thread it is likely because you desire to use threading with WASM WebGL As a heads up, certain System.Threading.Tasks appears to be a no-op in Unity 2019.3.9f1. Case #1243010.

https://forum.unity.com/threads/async-await-and-webgl-builds.472994/

 

As reported by Unity, Multi-thread support in WebGL is to internal UnityEngine features only.

C# threads AND Multi-thread Rendering is not suported yet and this feature is experimental.

 

Rafel_CS, the link you shared -- it shows the issue as being resolved. It also quotes a Unity representative who states it should work.

webGLThreadsSupport is set to 1 and this is functionality that worked in 2018.x. How long does Unity get to claim multithreading support if the actual implementation is broken?

 

The documentation says the "memorySize" property has been deprecated and has no effect on WebAssembly builds:
https://docs.unity3d.com/ScriptReference/PlayerSettings.WebGL-memorySize.html

 

That's curious because I had a recent WebGL deployment built with 2019.3.x which did require assignment of a larger memory size.

 

Hopefully a Unity staff member will weigh in on whether or not that field is actually still used. Doesn't make a lot of sense to remove such an important field from the UI but keep it functional in the code. If it is no longer used as stated in that documentation, I'm curious why that is - do they use automatic memory management now?

 

I believe that with the move to WebAssembly the heap size is now managed automatically, although you set an initial size. With the older asm.js backend the heap had to be fixed at build time (or edited in the json file).

 

@OneManEscapePlan @dave_oak I think the setting is still active. In a 2020.1 WebGL build I get a very specific error indicating that the heap is not being permitted to grow beyond an initial value that I set earlier. Details here: https://forum.unity.com/threads/uni...webgl-memorysize-deprecated-or-active.956076/

 

Do you have any plans or new information about WebAssembly Multithreading support?

 

Thank you.