Allow to read geometry directly from the GPU (VBO triangles layers)

[tmarti]

Context

This is the result of some fantastic conversation with @MathiasTribia and based on the initial code he did in ArrayBuf.js but that was not public 😎. Big Kudos Mathias! 🥂

Now I took the opportunity to work out some details and leave it in a really good working state 🎉. Perfectly working for VBO batching/instancing triangles layers!

Description

This PR allows to read back geometry data DIRECTLY from the GPU without needing to store all the geometry of loaded models into browser RAM.

Completely avoid the need for Scene::readableGeometryEnabled!

It's a tremendous RAM saver in case of needing to read back entities' geometry in order to do further processing/analysis on the Javascript side.

It's very simple to use! Use it like this::

const entity = ...;
const { indices, positions } = e.getGeometryData();

// now, have some fun with the geometry in `indices` / `positions` 🎉 

The fetch time is independent of the model complexity, and only dependant on the amount of fetched geometry.

Some tests fetching the geometry of around 3k objects indicate the geometry can be fetched for all 3k of them in less than 0.5s! 🚀

At the moment this is supported by both batching and instancing layers of VBO-Triangles implementations!

What do you think @xeolabs?

[dknezevic]

I really like the option to grab the geometry directly from the GPU as i am currently struggling with the Scene::readableGeometryEnabled option in order to do additional computations on the model.
Can't wait to test it!

[tmarti]

Any feedback here? 😊

[xeolabs]

Any feedback here? 😊

Coming up Toni, we just need to consider some use cases and how it coexists with the current geometry retention option.

[xeolabs]

Hi @tmarti, coupld of quick questions, as we work out strategies -

Would this be doable for DTX as well?
What's your use case for this feature?

thanks

[tmarti]

Yes, it would be doable, but we would appreciate it a lot if at the moment this could be merged and then the DTX support comes a bit later 😊.

The use case are certain use cases that need geometry processing. They don’t relate as much to the concrete use cases but to the fact that some geometry related tasks can be deferred until visualization time, which allows UI/UX related developments not depend so much on frequent updates to the processing pipeline, which for us is more efficient in terms of effort and development time.

Also, we sometimes manage big IFC files (>1GB) which are shown in mobile apps via WebViews, where RAM resources are more constrained, as the apps also use their RAM for their product functionalities. And, if extra RAM stress can be avoided with this PR instead of using scene::readableGeometryEnabled, this is a big win.

This PR would be a double win for these cases: avoid unneeded coupling with backend pre-processing, plus almost zero memory footprint in case we need to fetch geometry on-demand.

One potential concrete use case, even though it’s only an example, would be to offer an object inspection panel upon object selection that in addition of showing the object properties displays a short-lived instance of xeokit-sdk where you can inspect the single selected object from different angles.