Hi,
I am testing a custom URL for 3D tiles (not a Cesium Ion asset) using the 3D Tiles for Godot plugin (v1.0.0 - Windows), The 3D tiles are loading successfully; however, during debugging, I’ve noticed that the bounding volumes were not aligned correctly with the mesh.
For comparison, when using Google 3D tiles (Cesium Ion) they load correctly, but the bounding volumes may or may not align with the tiles. This suggests a potential issue where a double transformation might be applied, possibly from both the georeferenced transform and the mesh transform, while the tile transform appears to follow an identity matrix.
Could anyone provide insight into resolving the bounding volume misalignment or suggest if this might be related to an incorrect application of transforms? Any help would be greatly appreciated.
The wrong bounding volumes may have many different reasons, and the first pass could be to narrow down where exactly the error is caused. One approach for this would the to load that tileset in CesiumJS and look at the debug bounding volumes.
You could run a local server to server to serve that sandcastle on localhost, and then open a Sandcaslte with this code:
const viewer = new Cesium.Viewer("cesiumContainer");
// Create the tileset in the viewer
const tileset = viewer.scene.primitives.add(
await Cesium.Cesium3DTileset.fromUrl(
"http://localhost:8003/tileset.json", {
debugShowBoundingVolume: true,
})
);
// Zoom to the tileset, with a small offset so that
// it is fully visible
const offset = new Cesium.HeadingPitchRange(
Cesium.Math.toRadians(-22.5),
Cesium.Math.toRadians(-22.5),
60.0
);
viewer.zoomTo(tileset, offset);
The important point here is that debugShowBoundingVolume: It should visualize the bounding volumes accordingly.
The point is: When the bounding boxes are correct in CesiumJS, then what you are observing in “3D Tiles For Godot” is likely an issue of the plugin. If the bounding volumes are also wrong in CesiumJS, then they are very likely already wrong in the input data (i.e. in the tileset JSON itself).
The bounding volumes and 3D tiles are working correctly when tested in CesiumJS using debugShowBoundingVolume, and they render as expected. However, the same tileset shows issues when loaded through the Cesium for Godot plugin. This suggests that the problem may lie specifically within the plugin’s interpretation of the bounding volumes, rather than the tileset data itself or issue could be from how the scene is setup in godot
Yes, that’s a strong hint that it may be an issue in the plugin.
You could consider to open an issue in GitHub - Battle-Road-Labs/3D-Tiles-For-Godot: 3D tiles support for Godot as GDExtension and Engine submodule . Maybe someone from BattleRoad will chime in here as well (and maybe then can also take care of opening the issue). In any case: If there is any data set that can be shared publicly (e.g. as a ZIP file, here or in the issue) then this could help to track down what’s wrong there. Otherwise, this will have to be sorted out based on the issue description.
Hey there, absolutely, I’ll be taking a look at this, and, just as Marco mentioned, if there’s some specific tile data that could be shared to help us debug this within the plugin, that will be greatly appreciated…
I’ll tackle this as soon as possible, and we can track progress on the GitHub issue I just created:
I have used an api with key for the custom tileset, which covers only a small section of a city (approx 8km), anyways i am not be able to share the tileset or provide a sample zip at this time.
The absolute baseline test could be 3d-tiles-samples/1.1/BoundingBoxTests at main · CesiumGS/3d-tiles-samples · GitHub . But it’s unlikely that this is already “wrong”. There probably should be additional tests that include actual tile transforms. The important point here is that the tile transforms do affect the bounding volumes, and it’s easy to miss one transform, or accidentally apply the wrong transform to a bounding volume.
(I’ll take a note to create additional test data sets for that. But 1. that may have relatively low priority, and 2. there may be many degrees of freedom - you know, translations, rotations, scaling, non-uniform scaling, negative scaling(?), scale-then-translate vs. translate-then-scale, etc…)
