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.
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...
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:
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:
A longer term solution should probably be like this:
Alternative ā
No response
Additional context āļø
No response
Validations ā