ThatOpen
Make fragments more scalable with tiles
Description 📝
Currently, geometries are generated as a single binary file created with flatbuffers. This has the downside that the whole model data is handled as a whole and therefore consumes a lot of memory and has limitations such as:
- Makes it impossible to convert bigger IFC files to fragments.
- Makes it impossible to load bigger IFC files in more modest devices.
Suggested solution 💡
Some time ago, we implemented a POC for "BIM tiles", allowing to lazily load only items that were visible for the user. This is a deep rabbit hole, and an ideal solution would involved a geometry database that can stream the geometries.
I believe we should go for the easiest possible approach for a first step:
- Generate the bounding boxes of all geometries of the building in fragments.
- Make a special culler for bounding boxes.
- Instead of loading the whole .frag file, cache the it locally using indexedDB.
- Request sets of geometry to the .frag file as they are discovered in the bounding box culler.
A longer term solution should probably be like this:
- A backend buffer database only with geometries.
- A backend item database with IFC properties, locations, etc.
- The possibility to stream both geometry and properties to both databases as IFC are converted to fragments.
Alternative ⛕
No response
Additional context ☝️
No response
Validations ✅
- [X] Read the docs.
- [X] Check that there isn't already an issue that requests the same feature to avoid creating a duplicate.
- This is impressive topic, and I tried finding boundingboxes for each element by expressID. It seems that this code is no longer correct with count ===1
https://github.com/IFCjs/components/blob/main/src/fragments/FragmentBoundingBox/index.ts#L126. - So I changed a few things to find the boundingbox. It serves selectionwindow and selectionshape...
I'm investigating this these days, let's see if I can come up with something before the end of this week!