So… I had a short look at this, and have identified the reason for the behavior, but it’s not immediately obvious how to resolve this.
Analysis
… for curious nerds.
I uploaded that KMZ to ion. Looking at the resulting tileset did not help much, because … nothing is visible. A tl;dr is that setting
viewer.scene.camera.setView({
destination: new Cesium.Cartesian3(-801073.3215359622, -5488208.485999448, 3138821.543496793),
orientation: new Cesium.HeadingPitchRoll(5.666925725502479, -0.7806982622768279, 6.283185304491835),
});
will zoom to one of the cars/instances.
And for those who might not know what I’ve been talking about when I mentioned the “wiggling”, here’s a short screencap:
By default (for tests like this) I enable debugShowBoundingVolume for the tileset. And this one is actually somewhat … interesting:
Yup. That white line there is a bounding region. A single, huuuuge bounding region that essentially covers the entire globe.
The tileset consists of a single tile - namely, one I3DM file that refers to the GLB with that car. As mentioned above: The effect is visually what you’d might expect to be precision errors, as described in Precisions, Precisions | DME Component Libraries for .NET 2025 r1 . The solution is usually to define an “RTC center” (relative to center center (sic)) and store the positions relative to that. For I3DM data, CesiumJS is actually computing such an RTC center. And that usually avoids the jittering. But one can see what the issue is in this case: These are some of the positions that are stored in the I3DM:
They are nowhere near each other. These instances cover the entire globe. So the bounding sphere center is roughly the center of earth, and that whole “relative to center” approach makes no sense any more.
Possible approaches
I don’t know “the” solution for that from the tip of my head. What the tiler is doing there usually makes sense: There are many instances. This should become some I3DM. The fact that the instances cover the whole globe is not anticipated there.
(It’s unlikely that some ~“special handling” can be introduced there. I know, people are pretty quick to come up with solutions for something like this. These solutions are usually quick, elegant, … and wrong. E.g. “Check whether the bounding sphere of the instances is large, and split them into multiple I3DMs” - yeah, define ‘large’ and ‘multiple’…)
One approach could be to do this (“manually”), for this particular data set, with the knowledge that one can have about this particular data set. For example: One could split that KML file into ~50 KML files (each containing 20 instances or so), and hope that the tiler can process this in any way, and that it will create 50 I3DM files that do not expose this “jittering”.
A completely different approach would be to move this instancing to the tileset level. It should be fairly trivial to parse that KML file, and create a tileset.json that just contains tiles that refer to the model, each tile having the proper transform to put it at the right position. Of course, this would mean that it would not benefit from the GPU-based instanced rendering, and cause performance issues for a few thousand model instances.
(Somewhat related: Consider convenience functions to create instanced models · Issue #84 · CesiumGS/3d-tiles-tools · GitHub )
A mix of that could be to put more time and effort into such a functionality. Keep the metadata. Apply some K-Means clustering of the points. Compute the maximum error that is introduced by a certain RTC center, and minimize that. Some “research” could be done here (or some “hacks”, if it’s supposed to be focussed on a quick solution). I’ll leave it at that for now, maybe others want to chime in.
