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.
Transferable objects look very interesting…
“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
- 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.
Could we use the regular
Engine instead of
NullEngine since we have OffscreenCanvas?
That’s another good tool as well. If you only want to support Chrome/Android anyways. Not an option for my case, I wish
Important to note aside from offscreen canvas, that service workers are also useful if you want to make your web app into a Progressive Web App (PWA)!
Thanks for the suggestion… but I was thinking of going the Electron route (since it’s more of a desktop game)
Edit: @br-matt Since Electron runs Chromium it would have the API, so I would be less worried about compat.
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!
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).
there is a built-in worker pool here.
Babylon.js/workerPool.ts at master · BabylonJS/Babylon.js · GitHub
the auto release worker pool helps prevents memory leaks
Ah I getcha.
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.
I love the idea of using a service worker for the integrated server!
A big reason I was thinking of Electron is because I can use APIs that are chromium only, e.g. OffscreenCanvas, NavigatorUAData, and the Cookie Store API.