Add web export

[dsnopek]

Marking as a DRAFT because this builds on the changes from PR #37 which should probably get reviewed and merged first.

Web can only use the Compatibility renderer, which is why it depends on PR #37, in order to take advantage of the light management.

Some notes:

• In order to get around CORS on the Web, we need to add &origin=* to all the requests to the Wikipedia.
• Since this project uses threads, it needs to have "Thread Support" enabled in the export settings, which requires some special headers from the web server. For this to work on Itch.io, you need to enable the "SharedArrayBuffer" option:
  
  • Note: We could probably rewrite it to not use threads on the web, and eliminate this constraint
• For whatever reason, having 3D physics run on a separate thread would just crash on the web, so I disabled it. And also, for whatever reason, we can't override that option via a .web feature tag, like all the overrides I did on Add support for the Meta Quest #37, so I had to completely disable it for all platforms. :-( Is this setting important for other platforms? Personally, I've never had good luck with running either physics or rendering on a separate thread - that's always caused weird problems for me

Anyway, it does work in my testing!

And if we can get the web working, we can also try to see if WebXR will work, which would be another way to distribute the VR version ;-)

[dsnopek]

Nevermind, I got images working! So, this is only DRAFT until PR #37 is reviewed and merged

[m4ym4y]

That's really cool that this is possible! Thanks so much for getting this working!!

• As for the physics on a separate thread, I did notice it made a big performance improvement earlier in development but for some reason in the current version it doesn't seem to make much difference anymore. (It might have been before I moved a lot of the work into separate threads that I was noticing a benefit). I will test a little more to ensure that it doesn't make stuttering worse when loading exhibits (that was the main issue I had in the past because it seems like modifying a gridmap uses a fair bit of physics time)

• Does SharedArrayBuffer still have issues running on the web on mac? I could try removing the threading for the web platform but it's pretty deeply embedded in the game's logic. It does also help a lot with things that were otherwise causing large frame drops. I'm curious how some things on the web version are working, like the caching logic that uses FS operations, and the network calls

[dsnopek]

I will test a little more to ensure that it doesn't make stuttering worse when loading exhibits

Cool, thanks, let me know if you encounter any issues!

Does SharedArrayBuffer still have issues running on the web on mac?

Yes, there's still issues on Safari.

I could try removing the threading for the web platform but it's pretty deeply embedded in the game's logic. It does also help a lot with things that were otherwise causing large frame drops.

Doing the web requests without threading should be easy on the web, because Godot just hands the request off to the browser which does its own threading, and gives us the result when it's done.

But, yeah, loading the image data and generating mipmaps would be challenging to do smoothly without threads - we'd have to make a queue where we do just a little bit every frame, or something like that.

I probably won't have time to mess with it for at least a week, but I may experiment with it later - it's an interesting problem :-)

I'm curious how some things on the web version are working, like the caching logic that uses FS operations, and the network calls

On the web, Godot (via Emscripten) uses a fake file system on top of IndexDB - it works pretty transparently. And like I mentioned above, the network calls get handed off to the browser - they're done like normal AJAX requests from JavaScript.

[m4ym4y]

On the web, Godot (via Emscripten) uses a fake file system on top of IndexDB - it works pretty transparently. And like I mentioned above, the network calls get handed off to the browser - they're done like normal AJAX requests from JavaScript.

that's an awesome feature!!

still probably worth removing the caching behavior for the web version though as the browser can manage its own cache for the images and articles pulled

also "data" settings can be disabled in the web version

[dsnopek]

still probably worth removing the caching behavior for the web version though as the browser can manage its own cache for the images and articles pulled

also "data" settings can be disabled in the web version

Good point! When I can come back to this, I'll try disabling those things. (I'm doing a game jam for the next 7 days, so I won't have too much time until after)