WebGLWorkerRenderer

This is a feature idea.

The concept is simple: load the whole Three.js library inside a worker, make a scene as normal, then instead of rendering to a WebGLRenderer, one just renders to a WebGLWorkerRenderer.

This renderer will do the usual stuff that WebGLRenderer does: calculate world matrices and other CPU-blocking stuff, then send over a binary representation of the scene graph (SharedArrayBuffer) to the main thread. Maybe JSON would work too, especially for big scenes where stringify is small compared to the otherwise large amount of main-thread calculations.

On the main thread, a runner is responsible for querying the worker for data every frame, and on the main thread it will use something similar to a WebGLRenderer but with the computation parts removed, and it will render using the DOM canvas.

Of course, this is a simplified description to get thoughts going…

Author: Fantashit

3 thoughts on “WebGLWorkerRenderer

  1. OffscreenCanvas could also be a nice approach for generating dynamic textures using CanvasRenderingContext2D. AFAIK, currently only WebGLRenderingContext is available in browsers.

    BTW I already use WebWorkers for generating all my THREE.js geometries including the generation of an Octree for THREE.BufferGeometry. I also use it for Constructive Solid Geometry which would otherwise block my rendering loop.
    However, you have to be careful when transferring recursive algorithms to WebWorkers. I used this CSG lib which works good in browsers’ main thread. When I used it in a WebWorker I got many stackoverflow exceptions when applied to more complex geometries. The algorithms in the lib are implemented recursively. After some web search I figured out that maximum stack size in WebWorkers is much lower than in main thread. I changed the algorithm implementation to an iterative approach. After that, the CSG lib works within WebWorkers. This way, CSG can be done also for complex geometries taking a larger amount of time (in my app sometimes 2s-10s) without blocking your UI.

  2. I would suggest that this be explored with some examples before any new WebGLWorkerRenderer API is created… I’m not sure the arrangement of keeping THREE.Scene content on the main thread and ferrying it through Transferrables to a Renderer in the WW is the right abstraction.

    There is an OffscreenCanvas example now (#13253), IMO that is enough for general purposes.

Comments are closed.