CesiumGS
Regression in splats from PLY in 1.135
What happened?
Splats created from a PLY file via Cesium ion render differently in 1.134 compared to 1.345
1.134
1.135
Reproduction steps
Run the code in Sandcastle using the 1.135 version of Cesium JS. Then compare the same code running in the 1.134 version of CesiumJS
Sandcastle example
https://sandcastle.cesium.com/#c=jVNdc9s2EPwrN3pIqI4CSnKU1qnsqSonMV1LTmzajjSc6UDkSYQJAgwASZYy/u89fihxOm2nTyRwe4u9xWKMVqxzFmjFElzytXSjOEZrQ52hgpNIAUQt3F2kiw+xuBIXwe0+6E1FYAN1PYjHwZsgKz7fjS+OGYG+JB8yAgWDST94fXU/G1zd9LL5/e3gMrwWk4dPbhYGR/ObXj4P59n8IdtPw3g/u5+Iy/FFMSeyyX60nTy8s0Eu06Rch3F/sp/1p+GoO/3cZX+mr47Pg0yr2acvu8Vuf3Y82/3+jm+vHb/743wiH9SrTZHKdOuyqPVrpCIVa2UdbARu0cAJKNzCuB75rtrzolZcrcdaOS4UmqjVga+wknqBb2HJpUV4aldczuzga+lITeqERIuOWPmWC3fgrT9HZ2FdZkujc7J3ZGkRJN7r3tHP/cGbTs0E4PthKuw3skSjVS8dpHyDwEHqmDuhVQeshi2+NAhrK9SKSrlOUE64M+IRnIZC8hiBZHAH3Q50QZBG5AnoJSSGb6smEp0ixKgcuUGFcoXcuLTW8ozy7WGc0HBll9rkliG3bqoJfVuE+r14xOS94Tl6dTN8M4AI6Y+ro2r2M1wZROuVotqdGlt/K1uhuRxmSRaywohcOLFBy3iSeI0ttf/QGN007LXOQ92c3gAb/mfXfE4e0OwfhYvTa65W6K0VJZ1uOukAzZqyjwH8BF3WH3Tgl1rY4Tjfh1FRyF3lU/M8wLqdJKOXpdf4KKyz3yOBj85wS4lo5DBe3jqrt6thqa9R3OhrtHg1pg0vXvxHmVEU/gfk8JRvSqntaqJD3A7C6il+eBDPg1t1/itjNclTpJ6A0hmn4KEx2rS/Pw4tkUm9avYJTuBWpzWsTj0tUb+JvKAowdpIjzHfYU4Bptj4i3Wckb7Y2rJv6B9ahonYgEhO/uG9QizJZ6os11LeiD1GrdOhT/gf2qSugnC1QSP5jiCljGHaO72sC4yxoU/L8tC/9zqt5YKbZ7x/AQ
Environment
Browser: Windows CesiumJS Version: 1.135 & 1.134 Operating System:Windows 11 Enterprise
(For me, the console says
.WebGL-0x142406181000] 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.
which is the same error as the one in https://github.com/CesiumGS/cesium/issues/13016, but likely unrelated to this one)
(Except that when I created the test data for the other one, I already noticed what is likely the reason for this issue, but shrugged it off, because I was busy with other stuff. https://github.com/CesiumGS/cesium/issues/12682 might need an update...)
So that looks like a quantization issue. The given sandcastle does not allow sensible interactions like zooming and rotating (but these are unrelated issues). When extracting a single GLB from that file and creating a sandcastle for that, it looks like this:
Classic jittering. Precisions, precisions. The size of the bounding box is about 1.0 x 0.4 x 0.3. This should not be a problem in terms of the file format (SPZ). Quite the contrary. We'll only have trouble when the bounding box becomes too large (see https://github.com/nianticlabs/spz/issues/52 - but that's an unrelated issue).
In fact, that GLB can be rendered just fine with JSplat. As a quick sanity check, I "scaled" that data (just pragmatically scaling the positions by 100, and the scale factors (linearized) by 100), and wrote it out. Here is a screenshot of the original one, the scaled one, and what it should look like.
There's still something wrong., That may be an artifact of the "pragmatic" scaling, or some oddity in the coordinate systems because of that matrix, but maybe it's an unrelated issue. There's still some slight wiggling in the splat positions when dragging it around, but the overall shape is retained.
Maybe someone knows whether anything quantization-related changed in the last release.
For easier and more focussed tests, here are the single GLB and its tileset, and the "scaled" GLB and its tileset.
(We could also use a "unit cube"/dummy data set for tests like this, but maybe that's OK for now)
After trying to do some sort of "bisect" (and lots of swearing related to the breaking zip.js changes), I'm reasonably sure that this was introduced in 9c9c5eb360c54920104c2c596205d9ca6effa963 . This is just a hint/pointer, and should be confirmed independently. This commit was part of a PR that contains no test data and no spec updates. It ""fixed"" an issue that contains no test data and no description of what the ""issue"" actually was. Hopefully, the pointer to the commit and the test data that I posted above will help whoever has to ""fix"" this one.
Thanks @javagl, so that would point to something unexpected changing in https://github.com/CesiumGS/cesium/pull/12926.
@keyboardspecialist or @lilleyse, could you advise based on your knowledge of that PR?
From a random other context, another quick test: The following is an archive that contains a test tileset with splats, and a Sandcastle for loading it. The data set is a unit cube (size 1x1x1) with colored splats.
CesiumJS issue 13041 test tileset colors.zip
When rendering the tileset with the given Sandcastle at the origin, it looks like this:
When setting the tileset.modelMatrix to a position on the globe, it looks like this:
So what I referred to as "quantization issue" is more precisely (sic) a precision issue (I already mentioned "Precisions, precisions"): Apparently, at some point, the splat positions are multiplied with ~"the matrix" (that involves the model matrix), leading to the positions suffering from a loss of precision.
Looks kinda cool, though 🙂
A small update with what's probably worth noting for the investigation:
The issue does not appear when the tile.transform is doing the geo-placement! Here is a tileset JSON for the same data, with a tile transform that does the geo-placement, and this is rendered correctly
(Of course, the modelMatrix may not be set for this one)
The point is that the tile transform and the model matrix are somewhere, somehow, treated differently: The tile transform does not cause the issue, but the modelMatrix does.
That may be a relief or possible workaround: Whatever modelMatrix someone has been using, it should be possible to work around the issue by just setting it as the transform of the root tile instead.