[FEATURE SUGGESTION] Streaming support

[xeolabs]

Just starting off this ticket to track thoughts.

As I see, there are two types of streaming:

1. Continuously creating and destroying objects within the viewer. This would support a completely random traversal of an open-ended environment in which we don't anticipate how many objects there are. An example would be like in a flight simulator, where we fly across a terrain, loading buildings as fly near them, unloading buildings as we fly away from them.
2. Progressively loading a fixed set of objects, as we need them, keeping everything in memory once all loaded. This would support loading a building or city, starting with the objects we're initially interested in. We can interact with those objects while other less-interesting objects continue to load. Or we can defer loading of those other objects until we indicate interest in them (ie. looking at them, showing them in the TreeView etc.). But as opposed to (1) we keep everything in memory once it's all loaded. The user can also cancel loading of the model at any time, even when only a few objects have been loaded.

There are different implementation requirements between these two.

(1) would require an eviction strategy for stale objects, and an efficient way to repack batched scene representations. Pretty complex. I think this is more a "landscape traversal" thing, not quite xeokit's style.

(2) is much simpler for xeokit. This would require modifications to SceneModel that allow us to keep adding objects to it. The SceneModel could have the ability to call finalize() each time we add new objects, which would reallocate data textures and VBOs.

The SceneModel could

• be made so it never knows how many objects will end up in it, in which case it would need to deallocate then reallocate textures and VBOs. Probably inefficient.
• Or, it could know in advance how many objects will eventually get loaded, and pre-allocate the right sized VBOs and data textures in advance. That size could be specified in a header in the XKT.

(2) is basically where we have a model, but we only load some of it, the best bits, and are able to cancel at any time. Once we have all the objects in memory, we keep them there. The issue we address is shortening the time between loading a model and seeing what we want to see (eg. objects from the viewpoint given in a BCF ticket) then being able to abort the model and move on to the next model or BCF ticket.

Ideas

Proxy objects/metaobjects

• We could pre-load the entire metamodel in advance, so we can build the TreeView
• We could create all Entities up front, but only load geometry for them once we set their 'Entity.visible' flag true, or maybe set an 'Entity.loaded' flag true

We would need to be able to build the whole TreeView up front I think.

Would we then still load the XKT data into memory, but then create the actual geometry from it on demand? Or would the XKT be split, and only chunks of it are loaded (HTTP etc), as we need to create geometry?

Streaming based on split models

• We could rely on XKT's model splitting and make streaming load each split XKT part as a unit, as needed. Load all mechanical first, then load all plumbing etc.
• In this case, also still load the all the metamodels for the split parts up front though, so we can build the TreeView

Experiment with data textures for (1)

I started an experimental branch for (1), where I was going to have a dynamic create/destroy thing happening for data textures. That would involve pre-allocating a bunch of big data textures, then creating/destroying objects in those on demand. However, we need a separate data texture for each RTC origin, because the JavaScript execution space needs to rebuild the view matrix using the RTC origin, in double-precision JavaScript math. hence why we need to chunk things on the RTC origins. The GPU has the single-precision limit, so can't build it's own per-origin view matrix. That leads to a zillion data textures.

Also, it means starting a new type of model representation.

Seems easier to just retrofit the existing SceneModel and Entity with a lazy-object-create and multi-finalize capability as described for (2).

Here's the branch, for the record:

https://github.com/xeokit/xeokit-sdk/tree/streaming-scenemodel

[tmarti]

I have a question: does the BCF viewpoint DTO hold the set of all visible objects in the viewpoint? Or it holds just the set of objects of interest?

That is the base data you might have at load time and, it it is not the same, UX-wise, to:

• quickly load three doors and a window (the objects of interest), then the rest of the model after a delay

• instead of quickly loading all objects visible by the BCF viewpoint, then the rest of the model after a delay

(asking, as the implementation will depend on what data you have at load time)

[xeolabs]

The BCF contains the IDs of all the visible objects

[xeolabs]

The BCF also contains the camera eye, look and up, so could also provide the initial view volume