Configurable max geometry batching size for PerformanceModel and XKTLoaderPlugin

[xeolabs]

Allow to configure a maximum size for the batched geometry arrays that PerformanceModel creates on the GPU for batched geometries (ie. geometries that are not reused/instanced).

const perModel = new PerformanceModel(viewer.scene, {
    maxGeometryBatchSize: 20000 // <<--- Default is 50000000
});

Also support this new configuration via XKTLoaderPlugin```, which will configure it on each PerformanceModel```` it loads:

const xktLoader = new XKTLoaderPlugin(viewer,{
    maxGeometryBatchSize: 20000 // <<--- Default is 50000000
});

Examples

This update is currently in the master branch, where we have these examples:

• loading_xkt_maxGeometryBatchSize_20K
• loading_xkt_maxGeometryBatchSize_50K

Background

As XKTLoaderPlugin loads a model, it accumulates the model's geometry in buffer arrays, then once the geometry is loaded, creates WebGL VBOs from those arrays, then deallocates the arrays.

So, that's the heap grow-and-collapse we see while loading XKT models.

Pretty much all WebGL engines build CPU-side JavaScript geometry arrays as they load models, and will usually keep those arrays in JS memory. So for those engines, the heap grows and stays there.

In xeokit's case, in order to fit more geometry into browser memory, we don't keep geometry arrays in JavaScript memory, so once we've allocated the WebGL VBOs, we immediately delete the JS arrays, and so the heap collapses again.

The maximum size that is actually allocated in these arrays is determined by constant MAX_VERTS, which is defined here.

A lower value for MAX_VERTS would make the temp buffer heap size smaller, but would also reduce drawing performance for big models, since it would shorten WebGL geometry batches and result in more WebGL draw calls per frame.

It would be interesting to measure loading speed, rendering performance and (somehow) device stability for different values of MAX_VERTS.

So it's a trade-off - use a big chunk of heap while loading, so you draw more quickly while rendering. But if that causes instability on low-memory devices, it might be worth reducing that value, or somehow automatically calculating it (perhaps by sniffing the browser?)

A quick test of loading and rendering speed for various values of MAX_VERTS, using the Lyon example, which exclusively uses geometry batching:

MAX_VERTS	Loading time	Draw calls	Rendering perf.
1000	11.05s	5890	~5FPS
5000	10.17s	1272	~30FPS
7500	9.31s	880	~40FPS
10000	9.40s	682	~50FPS
20000	9.6s	374	~50FPS
5000000	9.4s	9	~60FPS