Workers & Babylon?

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?

1 Like

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.

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.

  1. Create a skybox, glow layer, highlight layer, reflection probe, and x-z plane
  2. Loads the models in the models folder
  3. 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.

Also…

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

Here is worker PG example - https://playground.babylonjs.com/#NMPB99#5

1 Like

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)!

2 Likes

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.

1 Like

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).

1 Like

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

1 Like

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.

HTH!

1 Like

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.