3d gauss splatting 3dtiles lod render error

[cuijianzhu]

What happened?

bug1: Access to XMLHttpRequest at 'http://ecn.t3.tiles.virtualearth.net/tiles/a132103233203120321321.jpeg?n=z&g=15420' from origin 'http://127.0.0.1:5503' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Cesium.js:7476 An error occurred in "op": Failed to obtain image tile X: 1749805 Y: 850614 Level: 20. Cesium.js:75 GET http://ecn.t3.tiles.virtualearth.net/tiles/a132103233203120321321.jpeg?n=z&g=15420 net::ERR_FAILED 504 (Gateway Time-out) bug2: 256[.WebGL-0x4ce400ebf000] GL_INVALID_OPERATION: Error: 0x00000502, in ..\..\third_party\angle\src\libANGLE\renderer\d3d\VertexDataManager.cpp, rx::VertexDataManager::reserveSpaceForAttrib:535. Internal error: 0x00000502: Vertex buffer is not big enough for the draw call. demo - 副本 - 副本.html:1 WebGL: too many errors, no more errors will be reported to the console for this context.

bug3:
demo - 副本 - 副本.html:1 Access to XMLHttpRequest at 'http://ecn.t1.tiles.virtualearth.net/tiles/a1321032332031203311.jpeg?n=z&g=15420' from origin 'http://127.0.0.1:5503' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Cesium.js:7476 An error occurred in "op": Failed to obtain image tile X: 437455 Y: 212652 Level: 18.
Cesium.js:75 GET http://ecn.t1.tiles.virtualearth.net/tiles/a1321032332031203311.jpeg?n=z&g=15420 net::ERR_FAILED 504 (Gateway Time-out)

bug4: part of the model is not rendered.

how to resolve these probloms?

Reproduction steps

...

Sandcastle example

No response

Environment

Browser:
CesiumJS Version:
Operating System:

[lukemckinstry]

Hi @cuijianzhu,
Thanks for this report. I think we will need more information to help us understand the issue. Are you able to provide us a working example with our sandcastle tool that reproduces the issue?
It may also help us to know:

• The environment (Browser, CesiumJS version, OS version) you are using
• Since the title of your post indicates you are trying to load a 3D Tileset with gaussian splats, can you tell us if you produced this tileset with Cesium ion or other means?

Thanks and I hope we can resolve soon when we have more information.

[cuijianzhu]

hi, @lukemckinstry
you can see my 3d gauss splatting model in sandcastle tool now， please wait for few minutes.
https://sandcastle.cesium.com/#c=bZBNawIxEIb/StiTFkkQDwVdpWB7K/Sg7SmXmB11aj6WTHatlv73Zr/AYk/DzLzPOx9oSx8ie2CK2BoIK8v2wVsmM91mMltIJ532jiKrEc4Q2JI5OPdq/tHWRoN+7V1U6CDIbLwYuIgGCGIC1VlhHNAuzJ63XZs3g9+DGUnH0vxjjCXNhXAHdF/8UJ3U1SoefSlmRWv4OBW9Mf8k72Q2acBvVlycsqg3OgC4Tak0vITgw5ztlSFgP0nWrNYdw0mDA14GtBixBuKqKEa977i9vRdevbdbf9vKJllO8WJg1Qx+wu6VVbqAcxHBlkZFILGr9CntqIkaKBcDkhdYMyyW/7yOaaOIUmdfGbPBK8hslYuk/4MZrwp0h7caglGXRnKcrl67Iuc8Fym9p6L3ZqfCjeMv

[cuijianzhu]

hi, @lukemckinstry , you can see my 3d gauss splatting model in drive.google.
https://drive.google.com/file/d/18WlCtQeEqUIJjWDYa2kdrlHpuF_zvGOK/view?usp=sharing

[javagl]

(The CORS point seems to be unrelated (or in doubt, should be tracked as a separate issue))

The hint to "wait a few minutes" refers to the fact that the server is pretty slow, and the GLB files are pretty large.

There are several things coming together here. There currently is not yet a full support for real "Level Of Detail" for splat data in CesiumJS. On top of that, the number of splats that should be displayed here is probably just too large. The first level of detail (below the root) consists of roughly 50MB of data, and a rough(!) ballpark estimate is that this will contain maybe 5 million splats. For comparison: The whole data set from the demo at https://sandcastle.cesium.com/index.html?id=3d-tiles-gaussian-splatting contains about 550000 splats. It's not clear what the limit is for the number of splats. We've seen similar error messages for ~"slightly more than one million splats". And in any case, I don't think that there is any mechanism that prevents GL errors when there are "too many" splats. So... there are several things to be investigated and to be taken into account in the ongoing development.

[javagl]

I created some dummy test data to reproduce the issue:

tilesets-2025-11-18.zip

The archive contains three tilesets with splats. Each of them is a quadtree with 3 levels. In the first one, each tile has 16³ splats. In the second one, each tile has 32³ splats, In the third one, each tile has 64³ splats. So in the third one, when the leaf tiles should be displayed, there are 4194304 splats. The archive also contains a sandcastle to load these tilesets. When zooming into the third one, one can see where things wreak havoc:

The smaller ones still work, so it's unlikely that this is a matter of ~"invalid files" or something like that. (Although I did have to apply some tweaks and fixes to bring the data into a shape that CesiumJS likes...).

The performance for the 4 million splats is dismal. It claims 30 FPS, but ... while I'm typing this, the typing is laggy - i.e. that open window (without any interaction) slows down the browser and the whole OS. At least it's warm here: The GPU usage of my RTX2070 is pinned to 100%, and the cooling fan goes brrrrr. In how far this performance issue is the result of that rendering error may have to be investigated, but without any interaction, I'd expect it to not keep the GPU at 100%.

[ggetz]

@keyboardspecialist @weegeekps Do either of you have any rough estimate on what the upper-bound of number of splats the sorting module is expected to handle?

[javagl]

I'd expect that to also depend (to some extent, probably, at least) on the shpherical harmonics degree. For the given data, the degree is 0. With a higher number of SHs to be stored, the limit may be lower.

[javagl]

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 appear. As mentioned elsewhere, I couldn't imagine a reason for that

Vertex buffer is not big enough for the draw call.

given that all this should be far away from any limits that the GL implementations should support. So from the symptoms, the next (still somewhat wild) guess is that this is a race condition where it "selects" the finer tiles with their additional splats, and tries to squeeze them into a previously allocated (smaller) buffer. But I have not yet spent time investigating the cause (that involves reading code). I just created the test data (that only involves writing code 🙂 ).

[javagl]

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 , by rotating the view while the tiles have still been loading. Something about that sorter or texture generation, probably...

[javagl]

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 here that uses inconsistent instance counts and buffer sizes, i.e. a debug log

  const expected = vertexArrayCache._attributes[1].vertexBuffer._sizeInBytes / 4;
  const actual = renderResources.instanceCount;
  console.log(`Draw command with ${expected} and ${actual}`);

inserted there prints

Draw command with 262144 and 262144 (printed many times) 
Draw command with 262144 and 3407872
There it is
[.WebGL-0x3bd40e140000] GL_INVALID_OPERATION: ... Vertex buffer is not big enough for the draw call
Draw command with 4194304 and 4194304 (printed many times)

[weegeekps]

@keyboardspecialist @weegeekps Do either of you have any rough estimate on what the upper-bound of number of splats the sorting module is expected to handle?

High. My stress testing that I checked in sorts about 2.2 million splats. According to my notes I did test with up to 5 million.

The GPU usage of my RTX2070 is pinned to 100%, and the cooling fan goes brrrrr.

To me, this indicates that it's not a sorting issue, but in fact something else. My guess is writing/updating the texture or something else causing blocking for a brief moment.

[javagl]

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 will work", so this has to be imposed as a hard limit in the traversal/selection/textureGeneration process. Right now, there is no such check. The texture generation has a limit as well: A tileset with (4 leaf nodes with) 16384000 total splats still works. A tileset with 28311552 total splats fails with a hard crash when trying to allocate the texture. (Details may be machine-dependent).

The sorting is slow.
One could say that there's not so much that we can do about this. But there is one thing that we can do, namely, sorting as rarely as possible. This is not the case. A debug log in this line indicates that it is sorting in every frame, even without interaction(!) (and note that there's another place where the sorting is triggered, a few lines below that)

There is almost certainly a race condition.
Maybe my first comments here have been misleading. It first appeared to be an issue with the number of splats. But apparently, a draw command is created with an inconsistent state, and the reason is (handwavingly) a race condition that is likely related to the sorter promise handling. (It's hard to be sure about that. I'm skipping some parts of a "rant" that I already posted elsewhere, and for now just say the state changes in that update function should be reviewed and documented...). Roughly: It has to be made sure that the vertexArray and the renderResources refer to the same state. This will likely involve time-consuming reverse engineering to figure out what the code is currently doing and which part of the primitive (and the things that are stored in the draw command) change "asynchronously".