Potree bug preventing cloud loading

[arjunskND]

[jallen-NextDroid]

Seems like this issue isn't related to the pose error. The point cloud disappears before that error appears

[midnight-dev]

Are those larger points a sparse version of the lane (like in a low LOD rendering as if the camera was far away), or are they hovering above where the lane would be? It's hard to tell from the perspective, but if it's the former, I've seen this occur in normal Potree.

Just to make sure before I go hunting for a snippet, does it look like the points get "stuck" in super low detail even when changing the camera position / zooming in (at the same GPS time)?

[arjunskND]

Yes, the points do get "stuck" in super low detail even if you try zooming in. You have seen this in normal potree? Below is another image of the same thing:

[midnight-dev]

Yes, the new screenshot made me certain. This absolutely occurred in Potree in a charity project I worked on for the state of Louisiana about a year ago. I'll try to find a copy of my notes from back then. I can't recall whether I fixed it outright or reduced its severity. I don't think I ever submitted a PR for it because I wrote it off as a weird edge case and later forgot about it.

[midnight-dev]

Hey folks. After an infuriating few days of trying to track this down, I think I found the issue. This isn't the elegant solution I was aiming for, but if I'm right, this is an issue with the converter. Unfortunately, this means you'll have to rerun every borked point cloud. The good news is that it doesn't require a recompile 👍

Use your typical arguments for the converter, but add on: --store-size 500

Why?

I could write a small thesis on what eventually led me to this, but the short version is that the default slice per sparse grid cell occurs at 20k points. This is why you'll typically only see this on the outer edges of your scans - the point count always runs low on edges away from the origin. Setting a low number for the stored size encourages the converter to split bounding boxes into finer detailed ones, which has a positive effect on the LOD. I only have a small handful of point clouds, and most are in an intermediate state of preparedness (i.e. not completely raw), but this works for me and I haven't seen any negative consequences. With exceptionally high-detail point clouds, this may create additional CPU / memory utilization while being rendered. I chose 500 points, though it can be lowered further if problems are still visible.

By the way, on some point clouds, there may be enough detail in the points, but due to the larger bounding box, the points are enlarged; it creates a chunkiness. It's supposed to help with visibility of distant points in large point clouds while making sure very close points aren't hilariously huge. In smaller point clouds with significant differences in bounding boxes, big points are very noticeable - changing the point sizing from adaptive to fixed should get rid of that. For consistency and proper LODs, I'd recommend incorporating this alongside the conversion fix.

Hope this helps.

[midnight-dev]

Addendum:

The converter fix doesn't seem to cover all instances where there's a weird LOD. There are edge cases that can produce such artifacts as well. I don't have many point clouds to test this, however. I believe one of the ways this glitch can manifest is entirely JavaScript-based, which is good news. If you have any custom code that traverses your point cloud nodes and implicitly or explicitly computes the bounding box/sphere, a stuck LOD could result in the node(s) of interest.

[jallen-NextDroid]

[jallen-NextDroid]