-
Notifications
You must be signed in to change notification settings - Fork 132
Startup
Ruben de Laat edited this page Jan 31, 2019
·
3 revisions
BIMsurfer 3 Startup
This part of the documentation is for developers of BIMsurfer 3, not for users
A lot of calls are done during setup, some of them are done in parallel to speed things up a bit.
- A specific revision is loaded (this can be a revision containing many "sub revisions")
- First a call is done to get a list of bounding boxes that lay far apart. For now the implementation sucks and also the results are not used, so this can be ignored. The idea is that for models that have "identifiable" regions that are very far apart (usually modelling errors), the user can select 1 of those regions, so that the bounding box of the model actually makes sense.
- The densityThreshold (D) is retrieved from the server. This is based on the roid, the amount of triangles we want in the default layer and which types to exclude (like opening elements)
- The threshold is a float, and basically points to a single object, or sometimes a few objects with the exact same density
- This also returns the amount of triangles below this threshold (TBT) and the amount of triangles above it (TAT)
- The total bounds (TB) are retrieved from the server, also the total bounds untransformed (TBU) are retrieved (these will be used for vertex quantization)
- Based on the GPU memory available (client setting), an estimation of how many bytes are used for a triangle (based on the settings as well) and the total amount of triangles in the model (TBT + TAT) a call is done
to retrieve a Set of geometry data ids that we need to reuse (GDR) in order to stay under a certain amount of GPU memory used. This has nothing to do with amount of data OTL.
- I think this is where we can optimize
- First of all, I don't think we need a list here, we can simply use the same threshold kind of mechanism, but now based on the "trianglesThatCanBeSaved" property of each GeometryData (?)?
- But the real optimization would be to not base this on the (also unknown) amount of GPU memory.
- Problem is, the server can pick the top+threshold 500 reusable objects no problem, and this works great when only the default layer is used, but it should do so in an octree-aware way
- Most probably there is not a lot of reuse left after this...
- To clarify, it should take the top 500, but omit geometries with less reuse than x, otherwise you'd always end up with 500 draw calls, even for very small models where obviously no reuse would be best
- I think this is where we can optimize
- Also for every submodel the bounds are retrieved as well as the untransformed bounds (these will be used for vertex quantization as well)
- Now the default layer is loaded (if applicable). A query is sent to BIMserver including:
- tileId: 0 (we are querying TileId 0)
- densityLowerThreshold: D (get all objects with a density below the given threshold)
- maxDepth: 0 (this means that TileId 0 will contain all the objects)
- Now the tiling layer is loaded
- An initial query is sent to bimserver to get the tile counts
- minimumThreshold: D (all objects above the threshold, basically all objects not loaded in the default layer)
- depth: max octree depth
- geometryIdsToReuse: GDR, this will be explained later, here we only send it so we don't have to generate multiple octrees
- This initial query returns a list of non-empty Node IDs + how many objects there are in a given octree node, the viewer creates from this the octree
- Then tiles are loaded
- For each tile:
- TileId: The ID of the tile being loaded
- densityUpperThreshold: D (as before) (densityUpperThreshold and minimumThreshold are the same, should be changed)
- reuseLowerThreshold: A user setting, default: 1000. This only has effect on the amount of GeometryData that is returned (not on the objects themselves). In this case all geometires used > 1000 times are omitted
- geometryDataToReuse: GDR, a list of geometry data ids that we don't want to send over the line, this is only used to minimize data over the line and has nothing to do with GPU reuse
- And then there is the process of loading the reused geometry data
- This basically queries for a list of ids (geometry data ids) that have been omitted in the tile query results, the resulting geometry is inserted into the correct tiles