Hi @pjiang9,
First, an update on `CesiumVoxelMetadata` not picking up statistic values from CesiumJS sample data · Issue #1830 · CesiumGS/cesium-unreal · GitHub – it turned out that the sample data itself was incorrectly specifying the min/max as individual floats. They should have been vec4 values instead. I closed the issue and submitted Fix statistics in sample voxel tilesets by j9liu · Pull Request #13468 · CesiumGS/cesium · GitHub to correct these errors.
Second, I think I understand the confusion and unexpected behavior; I will try to explain:
CesiumGeoreference has two Origin Placement modes, but most oftenly used is Longitude / latitude / height. This option positions the Unreal origin (0, 0, 0) at whatever coordinates you specify. Cesium will load all 3D Tiles relative to that point on Earth. However, this relative positioning all happens “under the hood” – you won’t see it as a user. So you’ll see tilesets move when you change the CesiumGeoreference origin, even if you keep the Unreal location at (0, 0, 0).
This means that the gizmo that appears for the object (the red, green, and blue axes) will always be at the Unreal location, even though the actual geometry may be somewhere else. You can
see this happen for other tilesets too, like the one in 02_CesiumMelbourne:
This is more counterintuitive for that voxel tileset because it’s large and positioned at the center of the Earth. If you’d like the transform axes to always be at the tileset’s center, then you should switch the Origin Placement mode to True Origin.
I acknowledge that this is unintuitive, and perhaps there’s a way to better communicate that behavior to users (or even change it!). But does that explanation make sense, at least?