Limit buffer geometry updates

[trommlbomml]

Description

I am writing a game where i regulary update geometry buffers. Not every frame, from none, some and many buffers in the size of multiple thousand vertices.

To keep my update smooth I already update the attribute buffers until a maximum amount of time has passed and defer further updates to the next frame.

That works well up what I have not directly on my control is bufferData() calls for all dirty attributes in the buffer geometry. Threejs updates all dirty buffers, which can be so slow that I have regular spikes. It would be great if you can somehow control this from the outside to limit the buffer uploads per frame.

Solution

I see two options:

1. Add a parameter to renderer.render(scene, camera) where I can pass a threshold in ms or buffer count. That limit tells to stop updating geometry uploads.
2. Add a general parameter property to the renderer considered in all render calls.

Alternatives

I could also as a workaround only mark a maximum amount of my buffer instances with needsUpdate, but the measuring is much more accurate and a general framework task.

Additional context

As its an additional optimization parameter, it does not affect existing code and should have no impact on performance.

[gkjohnson]

@Mugen87 I feel like there used to be a function that would allow for uploading or initializing geometry similar to initTexture, etc but I'm not able to find it. Perhaps I'm misremembering? It may be worth adding a function like initGeometry to support this.

It might also be worth commenting that the name "init" may also be a bit misleading since it looks like calling initTexture on something like a modified DataTexture instance will reupload the content.

[Mugen87]

There is compile() and compileAsync() for precompiling shaders to avoid shader compilation stutter during rendering.

There is initTexture() to avoid the texture data decode and upload overhead which can slow down frame rates. When using image bitmaps though, initTexture() is probably obsolete.

There is nothing comparable for geometry buffers. Potentially because geometry updates cause the least amount of overhead (on average) compared to textures and shaders.

AFAICS, @trommlbomml is asking for some sort of budgeting mechanism which is in general complicated to implement in WebGL/WebGPU because we can't track timings in a similar precise fashion like native apps. So any time related metric is probably hard to implement.

I'm not sure initGeometry() would be much helpful in this use case since @trommlbomml can already control the updates in the ongoing app via needsUpdate on a per-attribute basis. The real problem is to detect how much time is left per frame for tasks and determining that is hard for apps as well as for the engine. Like mentioned before, I don't see a reliable way for measuring this...

[gkjohnson]

The real problem is to detect how much time is left per frame for tasks and determining that is hard for apps as well as for the engine. Like mentioned before, I don't see a reliable way for measuring this...

As far as I can tell geometry upload is synchronous and therefore measurable - if initGeometry (or a similar function) was provided then the user could call it iteratively for a specified number of milliseconds and implement their own scheduler and it won't be needed in the three.js renderers.

const geometriesToUpdate = [ ... ];
const time = performance.now();
while ( geometriesToUpdate.length !== 0 ) {

  const geometry = geometriesToUpdate.pop();
  // update the position attribute array
  geometry.attributes.position.needsUpdate = true;
  renderer.initGeometry( geometry );

  if ( performance.now() - time > 16 / 1000 ) {

    break;

  }

}

Here's an example showing the time differences. Initialization of the buffer is significantly more expensive but you can see that buffer attribute updates start to become more noticeable at 1 million + vertices (at least on my machine).

---

@trommlbomml - can you provide some more concrete numbers and examples of the amount of data you're updating per frame?

[Mugen87]

Here's an example showing the time differences. Initialization of the buffer is significantly more expensive but you can see that buffer attribute updates start to become more noticeable at 1 million + vertices (at least on my machine).

The first render of the mesh also compiles the normal material. When profiling the calls via the performance tools, setProgram() (which also compiles the shader) takes more time than anything else in the renderer. bufferData() is is actually faster than bufferSubData() from the geometry update.

According to this measurement, I see less need for initGeometry(). That would only preone the bufferData() call which is not the root cause for the long frame time, afaics.

[gkjohnson]

The first render of the mesh also compiles the normal material

You're right - I forgot about the material compilation. But to be clear I intended to focus on the timing of the second render and to demonstrate that the geometry upload timing could be measured and passed along to the user for scheduling.

I see less need for initGeometry(). That would only preone the bufferData() call which is not the root cause for the long frame time, afaics.

From my initial comment - it might also be worth commenting that the name "init" may also be a bit misleading since it looks like calling initTexture on something like a modified DataTexture instance will reupload the content.

I used the name initGeometry because it aligns with the existing initTexture function even though initTexture will also update a texture if it's already been initialized. If I were to rename the function it would be better to use something like uploadTexture (and uploadGeometry) which better reflects the fact that it's not only relevant to unused textures or initialization.

[Mugen87]

Even if we can measure single commands, the engine would need to track how much of the frametime budget has already been passed for other commands and if there is enough room left for additional geometry updates.

AFAICS, the OP is requesting a feature that limits the calls of bufferSubData(). So the dev sets needsUpdate to true on a bunch of attributes but the engine does not upload all of them in a single frame. It tracks the remaining time budget and if depleted, it updates the attributes in the next frame. That means the engine also has to estimate how expensive buffer updates are (so if the remaining time is sufficient for the next buffer update) and also must honor commands after the geometry update (potential shader compilation or draw calls).

@trommlbomml Is that what you are looking for?

If so, this will be a very complex task and I doubt a there will be a solution any time soon. As a workaround the developer can estimate on app level how many attribute are likely to be updated in time and sets needsUpdate of other attributes in the next frame.