You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the most important objects to the user are loaded first, and
the loading process can be interrupted at any time.
A use case would be:
user opens a BCF issue
the viewer sets the camera position to the viewpoint in the BCF issue
the viewer immediately loads the objects that are visible from that viewpoint
once those objects are visible, the viewer continues to load other objects that are not visible from that viewpoint
at any time, the user can abort loading; perhaps because they have finished looking at the BCF issue and are moving on to the next issue etc.
Considerations
Metadata
How do we handle metadata?
In xeokit, metadata means the information about the IFC elements. We load a collection of MetaObjects, each of which holds the IfcElement ID, name and type, and a collection of IfcProperties.
The xeokit's tree view (TreeViewPlugin) then builds a hierarchy of nodes that represents the containment hierarchy of the MetaObjects. Currently, this happens on one shot, where the TreeViewPlugin expects all the MetaObjects to be all loaded up-front.
If we are to use TreeViewPlugin with streamed loading, then we would need to adapt it accordingly.
Ideas
convert2xkt currently partitions model objects into tiles, called relative-to-center (RTC) tiles. Each object's coordinates are relative to the center of its RTC tile. This mechanism is used in the Viewer to render double-precision coordinates.
convert2xkt could be extended to also output a JSON kd-tree in which each node registers the objects within it. Each node would have the World-space axis-aligned-boundary of it's objects. Each object would be registered as its ID, plus a reference to the XKT file that contains it.
The Viewer would begin by loading the kd-tree JSON.
After positioning its camera (eg per the BCF viewpoint), the Viewer would then find the nodes in the k-d tree that intersect its current view frustum, and then begin loading the objects in those nodes.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
What streaming means in our case
By "streaming" we mean
A use case would be:
Considerations
Metadata
How do we handle metadata?
In xeokit, metadata means the information about the IFC elements. We load a collection of MetaObjects, each of which holds the IfcElement ID, name and type, and a collection of IfcProperties.
The xeokit's tree view (TreeViewPlugin) then builds a hierarchy of nodes that represents the containment hierarchy of the MetaObjects. Currently, this happens on one shot, where the TreeViewPlugin expects all the MetaObjects to be all loaded up-front.
If we are to use TreeViewPlugin with streamed loading, then we would need to adapt it accordingly.
Ideas
convert2xkt currently partitions model objects into tiles, called relative-to-center (RTC) tiles. Each object's coordinates are relative to the center of its RTC tile. This mechanism is used in the Viewer to render double-precision coordinates.
convert2xkt could be extended to also output a JSON kd-tree in which each node registers the objects within it. Each node would have the World-space axis-aligned-boundary of it's objects. Each object would be registered as its ID, plus a reference to the XKT file that contains it.
The Viewer would begin by loading the kd-tree JSON.
After positioning its camera (eg per the BCF viewpoint), the Viewer would then find the nodes in the k-d tree that intersect its current view frustum, and then begin loading the objects in those nodes.
WIP..
Beta Was this translation helpful? Give feedback.
All reactions