Bounding volume computation improvements #79
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I did examine the computation of the oriented bounding boxes (for point clouds, and in general) a bit more. The reason for the bounding boxes not being very tight is that the current In the last commit, I replaced this function with one that computes the oriented bounding boxes using https://github.com/Esri/dito.ts For a test, I generated 5x5x5 "point clouds" with varying numbers of points (200....25000), randomly distributed within boxes, with different sizes and orientations. For each of them, I computed the OBB once with CesiumJS and once with dito.ts, measured the computation time and the volume of the box. The computation with dito.ts is noticably slower (very roughly by a factor of 6), but in nearly all cases, the bounding volumes are smaller (sometimes by a factor of nearly 3). The proof is in the pudding: Here's a visualization of the results:
(the data is attached below). Overall, I think that it makes sense to use this function for the computation of the bounding volumes when creating a tileset JSON. The computation is not really "time-critical" in this case. And "bad bounding volumes" can lead to "bad runtime behavior". What remains to be done here:
The data (all GLBs with two tileset JSON files) is here: orientedBoundingBoxComparison-2023-11-07.zip Timing results: |
|
As another example, the new output for the data that was shown in the first screenshot of the first post here:
The bounding boxes originally had been rotated a bit, but now are basically as small as they can be. |
This was referenced Nov 9, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Addresses #58 and #69 (and may eventually fix them).
(It builds on #75 , so that should be merged first, but there is not much "overlap", so the changes here could also be retargeted to another branch)
The
createTilesetJsonfunction takes a set of tile content files, and creates a tileset JSON file from them. Thus usually boiled down to computing the bounding box of a GLB, and eventually, creating an axis-aligned bounding box. As pointed out in #47 (comment) , this will usually not yield a very tight bounding volume.The
mergefunction receives multiple tilesets, and creates a single tileset from them - basically by creating a new tileset where the root node refers to the root node of the other tileset as its children. As mentioned in #69 (comment) , this used some "legacy" functionality which created bounding spheres for the result.This PR adds a few new functions, mostly in the
BoundingVolumesclass (and corresponding updates in theTilesetJsonCreatorandTilesetMerger) for better bounding volume computations. The summary is, roughly:TilesetJsonCreatorandTilesetMerger). This basically means:Applied to the content that was provided by @sweco-sekrsv in #47 , this will yield better results;
The (single) test case for the
mergeoperation does no longer create a bounding sphere:The test cases for
createTilesetJsongenerally yield tighter bounding volumes:(There is not much difference for the point clouds, and one could expect better ones to be computed there - this still has to be reviewed...)