Three.js: How to load an animated .json model from a web-worker?

Question

Preamble

I've been banging my head against this one for almost two weeks now, and am no closer to a solution. I've asked sub-questions I thought would lead me in the right direction:

• Three.js - How to deserialize geometry.toJSON()? (where is geometry.fromJSON?)
• Three.js: How to create new 'morphing' geometry if I have all necessary buffers?

Of these, the second is still relevant, but no one seems to be biting, despite the bounty. So I am now asking the full question directly, and I will try not to make any assumptions. (Hints to) a solution would be greatly appreciated.

Question

I have several large animated 3D models in .json files, such as might be loaded with THREE.JSONLoader . They have a format somewhat like this:

{
    "metadata": { "formatVersion": 3, ... },
    "vertices": [...],
    "normals": [...],
    "faces": [...],
    "morphTargets": [
        { "name": "...", "vertices": [...] },
        ...
    ],
    "morphNormals": [
        { "name": "...", "normals": [...] },
        ...
    ]
}

I've been able to get the animation working when doing everything from the main thread. But loading and processing these large files freezes the GUI for a long time. So I need to delegate all this to a web-worker , and then successfully create the animation in the main thread.

Moreover, I need to send the result back to the main thread through transferable objects , so that there is no cloning of raw data blocking the main thread. As I understand it, WebGL uses Float32Array s, the buffers of which are transferable objects. So I'm sure this can be done.

The required process, as I see it, is as follows:

1. (UI) ➝ send filename ➝ (worker)
2. (worker) ➝ download ➝ process ➝ send buffers (including morphTargets) ➝ (UI)
3. (UI) ➝ reconstruct animation without copying any buffers

It's 2 and 3 I'm having trouble with. What buffers need to be created in the worker, exactly, and how do I make them behave as a proper ( Buffer ) Geometry on the UI side?

What I've Tried

I am aware of a related question already existing:

• How to efficiently convert THREE.Geometry to ArrayBuffer, File or Blob?

But the question seems dated. It is likely that I should be using a THREE.BufferGeometry , which isn't mentioned (maybe because it didn't exist yet). The accepted answer is a bit convoluted, and requires me to still do some raw work in the main thread, like downloading the model and rendering it to generate the buffers.

As it turns out, BufferGeometry doesn't support animation yet. One satori99 recently submitted a pull request to add this support. I've been playing with that code, but have, as of yet, been unable to apply it to my situation. It seems the support is still quite incomplete.

Here is my latest bungling attempt to get this working:

• main thread (communication with worker)
• main thread (using the BufferGeometry)
• web worker

Answer 1

I think I may have had the same issues as you, when I decided to hack around it.

I came to the conclusion that using THREE.Geometry at all was the problem, and focusing on creating JSON files that use the JSON Object Format 4.3 directly was a better solution.

This format stores all data in TypedArrays and no computations have to be done on these when loading/parsing. So it is a lot quicker to load, and in most cases I didnt have to bother with usung workers as there was no longer any pauses during loading.

Unfortunately, this format is missing a lot of the features that the old JSON format already supports. But it is the future preferred format for three.js json assets, so it will change.

As far as morph animations go, the existing shaders will work just fine as long as they get passed the right buffers for morph data, but the current WebGLRenderer does not do this for BufferGeometry, only regular Geometry.

This is the main roadblock for BufferGeometry morphs.

I followed the same internal logic that the WebGLRenderer uses to create the buffers for regular Geometry when I created that PR, but it is possible that the renderer code has changed a bit since then. Especially in the dev branch.

I will have another look at it this week. Because I have a need to get this working for a project of mine too :)