I’ve been looking into using workers for a game I have that uses Babylon, and was wondering if we could use workers with Babylon.
As an example, my game can take more 500ms to generate a level, which completly blocks the main thread (and therefore, the UI, which could be frustrating for players).
This Stack Overflow question mentions latencey depends partially on how busy the main thread is
This video by SimonDev shows that latencey also depends on how much information is copied and how many workers per cpu thread.
Is there a way to moving rendering and mesh stuff with Babylon.js to a seperate thread and keep the same level of performance so the main thread isn’t blocked?
I have been working on this now and have a similar thread, more about asset loading though. It really depends on what you mean by generate a level but one one thing you can look at is Transferable objects - Lightning fast - Chrome Developers if having a bunch of separate array buffers is okay for you. There is NullEngine which you can use in the worker to help there and other ways.
I have been experimenting with SharedArrayBuffer. You can use this to write/read data without using postMessage. It means learning the very basics of Atomics - JavaScript | MDN I have been trying to use it for assets but putting values and json in there is much simpler.
“generating a level”:
TL;DR: Create a new Scene and generating some in-game structures. This includes loading some assets as well.
If your interested in the details:
The project is here.
the generation is instantiating the Level class from core.js (which extends BABYLON.Scene), which has a few main parts.
Create a skybox, glow layer, highlight layer, reflection probe, and x-z plane
Loads the models in the models folder
Generates a new region of the world (the starting region), including a star and a random number of planets (currently 1-9) - I plan on adding more “structures” (e.g. asteroid belts and space stations) later, which would further impact performance.
Out of curiosity, are there specific features of Electron/dekstop are essential for your game? A PWA might also satisfy those requirements while still allowing you to package and publish your game to an app store!
Users might also appreciate not having to run “Yet Another JavaScript VM” with all the weight that carries, although a games might increase a users’ tolerance for that
The only thing that may be really useful would be running an integrated server from the node.js side and being able to connect to that - either for a simplified saves system and/or local multiplayer. Also having access to client hardware details for debugging and access to the local filesystem (since then I wouldn’t need to use the horribly hard to work with IndexedDB API).
Well, PWA has ability to access local file system, and SW fetch handlers would allow you to write your code in a way that allows you to seamlessly swap between local “server” (service worker) API calls and ones sent to a remote server for e.g. multiplayer.
It’s true though, at the end of the day you’ll have more control and lower-level access with an Electron app than a PWA, including ability to control what rendering engine is used.