Marco Hutter

A quick test with a single (root) tile with 4194304 splats does _not_ seem to generate this error. The performance is still dismal, but the error does not seem to...

For what it's worth: The plot that this is rather a race condition thickens: After a few tries, I could reproduce the error with the official sandcastle at https://sandcastle.cesium.com/index.html?id=3d-tiles-gaussian-splatting ,...

I tried to zoom into that a little bit, but will stop here. The latest state that I've been tracking to down to is that it generates a [draw command...

There are several interconnected issues here. Figuring out what the upper number is for _the sorting procedure alone_ could be worthwhile. After all, when this number is exceeded, then "nothing...

> > sorting in every frame, even without interaction > > Yeah, that's a major issue then. I had another short look. The check at https://github.com/CesiumGS/cesium/blob/bcc5ea383e294c698940dbf9df76ac5ba6961a73/packages/engine/Source/Scene/GaussianSplatPrimitive.js#L839 should probably be done...

The problem itself _did_ receive some attention. And we already noticed that (contrary to what I originally suspected) the reason is not the _number of splats_, but a race condition....

The reasoning sounds convincing, and the proposed fix is in line with my (subjective, shallow) understanding of what the `update` function is doing, and what the reason for the error...

It's hard to see. I found it easier to reproduce when the window was large (maximized), and zooming out very far very quickly. The following is a capture of that...

I have never looked closer at clustering, and am not sure how well-defined its behavior is. But I think that the effect can be observed quite easily when RIGHT-mouse dragging...

@lukemckinstry The linked PR at https://github.com/CesiumGS/cesium/pull/13064 was opened by Duan971231, and (I assume) should already fix the issue. (I haven't tested it yet, though...)