More robust handling of maximum texture size for non-color data, slight perf improvements for large point clouds #5229
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.
What
Point cloud builder uses now
DataTextureSource
for all its data.DataTextureSource
is now better at dealing with the max texture size: data writes are clamped ahead of time, meaning we no longer reserve memory for data that we can't write into the texture uponDataTexturesSource::finish
.This bubbled up now since
PointCloudBuilder
so far used a vec for positions and checked that against the maximum. The changes here leave the check in place, but makeDataTextureSource
reserving & writing clamp to the maximum and deal with this robustly even if high level data structures (likePointCloudBuilder
) fail to handle this.Artificially limiting the data texture size to 256 * 256 looks like this:

I tested performance before/after on these changes on two opf scenes on my mac to check for changes in perf and found the switch to using
DataTextureSource
for position/radius improved performance slightly:(numbers via performance metrics, release build)
Checklist
main
build: app.rerun.ionightly
build: app.rerun.io