But rebuilding a textured LOD2 city (about 65k buildings) and my FME 2024.1 workflow keeps dropping UVs, while ArcGIS Pro 3.3 bloats the tileset size by about 40%… What’s working for you right now for clean 3D visualization — Cesium ion, 3d-tiles-tools, PDAL+Blender, or something else that keeps LODs and materials intact?
A single change that fixed UV loss for me was exporting via 3DCityDB’s exporter straight to GLB, then running gltf-transform ktx (UASTC) + prune; materials stayed intact and size dropped about 35% versus Pro — @mjones76 I’ve found it steadier than gltfpack for packed textures: https://gltf-transform.donmccurdy.com; do you have 3DCityDB in your pipeline?
Skip FME here: CityGML → CityJSON via cjio → GLB, then gltf-transform with meshopt + UASTC, but leave texcoords un-quantized (e.g., --texcoord 16); that stopped the “FME 2024.1 drops UVs” issue for me and shrank the tileset cleanly. @mjones76 is right about splitting LODs first, but the CityJSON step was the real fix on a about 60k set. Are your textures atlased or per-building?
I ended up bypassing FME 2024.1 by loading the CityGML into 3DCityDB and exporting a tileset with KTX2 textures + Draco (https://github.com/3dcitydb/3dcitydb-3d-tiles); that kept UVs on a textured LOD2 (about 65k buildings) and came out smaller than Pro 3.3. Are your textures external or embedded? The only caveat is the DB import adds a bit of setup, but it’s been repeatable.
, the UV drops hit me too — baking all textures to KTX2 upfront (toktx --bcmp, power‑of‑two) and telling the tiler not to re‑atlas kept the LOD2 UVs intact in Cesium; KTX2 tools: GitHub - KhronosGroup/KTX-Software: KTX (Khronos Texture) Library and Tools. On the size side, my “about 40% bloat” in ArcGIS turned out to be attribute payload — stripping fields down to just a stable building ID before tiling cut the tileset way down. Are your textures already KTX2 and are you carrying lots of per‑feature fields into the batch table?