koobas.hobune.stream
What is unity WebGL export's correlation to Node.js?
Hello world!
We're trying to play around with unity's webgl export and for reasons of running our client on certain platforms we already have in place I'd like to find out more about why there are so many references to node in our webgl build.
We're trying to get it to run on node but so far there are so many checks where it tries to find out whether it's a browser or node, it gives me the impression that there's a correct way to run it on node (maybe unity tech devs do it for debug purposes).
So far we're just trying to hack around the checks but if anyone here has any info on this that would be lovely.
We found a variable called ENVIRON$$anonymous$$ENT_IS_NODE anyone know what this is responsible for?
We are also looking into this, getting stuck with the Filesystem (loading data). The development build seems to point to Node in many ways, while still "expecting" navigator or windows objects. What's the best way to take a WebGL export for Node (to use code for a backend server)
Hello @Wisearn.
It is indeed possible to run WebGL build in node.js (as well as in other shells). However, it would require some manual adjustments, because even though most of the Emscripten code is ready for node.js, some JavaScript plugins developed for browsers have not been fully tested in shells, so, depending on the Emscripten and Unity version, you might get exceptions when, for example, window object methods are used in plugin code, because those are not available in node.js.
So basically there are two possibilities:
a) you can patch all the build code and plugins to make it compatible with node.js
b) you can define a window object as this and override some of its methods (i.e. navigator, XMLHttpRequest etc.) prior to loading your build, so that when you start your build, it will think that it is running in a real browser, and not in the shell.
The second approach seems to be much more universal to me, because:
- you don't need to patch the build code
- you only have to implement such a wrapper once and it will work for future versions of Unity
- you can use the same approach to run your build in other shells.
Still, there is one problem that would be a bit complicated to solve. It is the canvas context functionality (used in gl functions), which does not exist in node.js. Even though there is a working example of a headless canvas in Emscripten code, it is not functional enough to cover all the Unity calls (unless you spend some time to make it work). However, if you just want to test your code in a shell, you can try to create a Development build, which should use a native NullGfxDevice when WebGL context is not available. To check if this functionality is available in your build, disable WebGL in your browser settings and try to run your build. If it runs well with a black screen, then NullGfxDevice code is included in your build and it should also run well in a shell without additional adjustments (otherwise it should print "Could not initialize WebGL context. Failed starting Unity." in the console).
Final solution might also depend on your Unity version (due to usage of different JavaScript plugins). I believe you can do this most efficiently in Unity 5.6, because its loader is independent from the build, so it should be sufficient to just override some of the loader methods to make it load any 5.6 Development build. If you are ok with those limitations, I can prepare a working node.js example.
