3D Tiles createTilesetJson: model aligns at origin but drifts far away

[huynhphanson]

I am converting IFC models into glTF/3D Tiles. When I use createTilesetJson with the flag --cartographicPositionDegrees, the model’s origin is placed correctly at the geographic coordinates I want.

However, when the model spans a large area, I notice that positions farther away from the origin are not aligned accurately. It seems that the local axes of the model are not perfectly aligned with the Earth’s East-North-Up (ENU) frame at that location.

I see that --rotationDegrees allows me to apply a rotation (heading, pitch, roll) to fix the alignment, but my question is: how can I determine the correct rotation angle that should be applied?

[javagl]

There currently isn't any real tooling support for determining this angle. It might be possible to create a small CesiumJS sandcastle that can help with finding the right angle. I do have some snippets that may be helpful for this, but will have to extract/assemble them for this particular task. (I'll try to allocate some time for that and post the result here).

Just to confirm: From the description and the screenshot, it sounds like there is loooong road, and one end of the road is placed at the right position, but the other end does not align with what you'd expect from the underlying imagery.

Is this correct that one end of the road is the origin (0,0,0) of the glTF model, and this is put at the right position, and the screenshot only shows the other end, which could be fixed with a tiiiny rotation of maybe -0.5° around the up-axis?
(Certainly, for a long road, even the slightest deviation in the angle can cause the other end to be several meters off....)

[huynhphanson]

@javagl Thank you for your reply. Yes, my model is indeed a very long road.

My goal is to combine drone photogrammetry models with BIM models in IFC format on a Cesium-based map inside Three.js. Right now, I already have a working pipeline: I use 3d-tiles-renderer to display the drone model, and for the IFC model I convert it to .glb (by BlenderBim or IfcConvert) and then load it with GLTFLoader. Both parts work very well.

However, as the project scale grows larger and the number of .glb models increases, things become more complicated. Even though I apply multiple compression tools, the total file size is still very large. This makes my website very slow to load initially, because it has to download all the models before anything can be displayed.

That’s why I want to experiment with making .glb models behave like tiles, in order to speed up the page load and rendering. Or — do you know of any other techniques for handling IFC in Three.js?

Here is a comparison image, both showing the same .glb file:

• On the left I use GLTFLoader (everything is in the correct position).
• On the right I use createTilesetJson to convert the .glb into a tileset.json.

[javagl]

That’s why I want to experiment with making .glb models behave like tiles, in order to speed up the page load and rendering. Or — do you know of any other techniques for handling IFC in Three.js?

There's the potential for asking many engineering questions here (you know, those where the answer always starts with "It depends..." 🙂 ). The Cesium ion design tiler from https://cesium.com/platform/cesium-ion/3d-tiling-pipeline/design-tiler/ allows converting IFC models into tilesets, which includes converting the actual geometry data into GLB. There are different approaches for improving the "perceived performance". One experiment that I did quite a while ago was to just take a GLB, and convert each mesh.primitive into its own, small GLB, and then use these GLBs as tiles in a tileset. This way, the (complex) GLB model could be loaded as a tileset, with the "sub-meshes" (primitives) loading incrementally. This still does not touch the huge topic of "Level Of Detail", where you'd use simplified GLBs for the actual streaming and incremental refinement.

However, back to the alignment question:

Here is a comparison image, both showing the same .glb file:

That's a bit surprising. How exactly are you doing the "geo-placement" in the GLTFLoader? Does the glTF itself already contain the "geo-location", or is this somehow done manually in the application?

Given that for a long road, the slightest error in the angle could cause a huge deviation in the position at the other end of the road, it might be that the difference here is caused by some inaccuracy of the computation of the transform in the createTilesetJson command. (The translation that results from a cartographic position is huge, and when this is all baked into a matrix, even an entry that is "wrong" by 0.0000001 due to some epsilon-error could explain this).

Is it possible to share this GLB file (either as a ZIP here, or in doubt, as a ZIP to marco at cesium.com)?

Otherwise: I just "cleaned up" a bit of that might help to find some right angle here. I extended some local snippets into some sort of an "editor". Then you change the angleDegZ in the following sandcastle, then this might bring some insights about what the right rotation angle could be:

https://sandcastle.cesium.com/index.html#c=xVp5c9u2Ev8qGL15EzmhaN2HY3vqJj08k6aZxOmrFOUPiIQljilCQ0KO3Y6/+9tdALxlO3acdJpEJBa7i98e2AXoyShR7DIQX0TMjlgkvrBXIgm2a/cvetecNzx6fiUjxYNIxPPG3st5NI/299mrWHAlmFrBnyAUiVAsiOhRM5xHHrG3g0eMf+GBshL0P73XZ3rYPY/l+lRGJwk8nPrNfns8HKIszcxNPBEJdxMH60AFlyJxue83DetUpQ9KxlqjIAIyHjIV8yg5l/GayXMaiKXUKjmMRz4LVAK0lyJOhEsszoAmlF5+agITuWIcWPPNJgyEz74EakXshB+ATHgOQ7bil4J4KMkUv0BFgsQITNUIIhjlnie3kXLZSZhIh31ZCQKOJi+FbG1C7om1iBRDVPKCgKHVAaVk2DtaMi2dllNccCo/1RTnLwTzeOSJMAR+cqtcazMD33uYe5ZOPbKm+4OrOLjqu14oI2GN4KIgNxWENrG8SJ87eBmq5jxitdIdHMg5qJnX3JtHmfnBoh5PVCjYx1MGOm03Vgn0oj+kL0KQ/C+yAvL/rQQAFBNKsJJloLa+2A+50j9WIliuFLJRQbRMWLKS29A3c32hRLyGiKDZ3FNb8Jii6Qz+Fp5MaKQdA/5/ds7DRDxzkDBiMgqvjTJF/zNTcw6Ib/Dn9W9CvrMSDxixI6TS9bwWywPWGg3czqALMaUHzRJprDdxJ/3hZDSgIb3oP3B1yQFrO4gsCS/FBbKQNJZ71NP+hnlu26kdm94yNrNjOYmxVEQBsboEGB3MML5YxgISABKAm5NDL4SZBNYGP1LgzjrQ2Lzxu+A+GPBdoLzVexmG84ZD8WtmtGDNRACekYmLIT59NktpNji7hmKaUsTAuobgbzIVag9o56Cxr6bVV2UgPgDqqN85uJmMyRsSeCWAW8dMpedp6Xlmnw2fn4OI1gk+RW622CoFigJM/0jMMoV8gnPw9Zk0CRq8axt5tLTmno6hEkUTA5Gxm/tIhEQOIYLvsoDxID5xIo2lXv0K3tbKrpLlFLjROeH5c3jxnL2S683W7FVrygJrSh+pYjaJsgVPMBXqfczbxjGwJhZpGjB7XJLPNUhBVD/FkHTiKGH/mvx0Q26cl4l0+/MoXZCndTMYUo7Sc+1KaV/jsdKbDo9Y4INSgbous2U61a0zFrtSdunl6etf3p6dnk11IiWJp+dMRHwB+4KjEw0tupDgDkxO2JE4DaNLHm5FQrlri9Ai4nrJ6BiwmnlDAIwskjGsbrtB5zgPrpAy5msxbxg+xmC0E5MKSaHy4NqZllAaRGwjkwCxBXNem+kxqtRab0MVwGJQdKCyXbweyEqCBTh/ljIUPGqm+4lbodJOGJyzZnXI+q4WkE/SwPvtdr2AmitjnR/XXNOZWQavnZgNF+fl03vdxPx4cSYGRs32nb5KXDTjW7Tix82Z/BVN+CtasKm5sLTuA1eGXzzqUcn3WmfzZn6tTn59TkHpPc3N6lZyZGvfZi4GnKLqTj4+TL5Ivf4k9fTc7oReVOM/dX4DLFKfynGoeFZ1z6wzRpVK67uDx/RePKa38pjdi8dsB49iC5EZ2rhAdT3OjoHprgHakHetYEfKQy87y8iqyhhh9cWlFXcvT6toU/G2iqPZeoG8zFQv1r100ZP1ANmeY9hAlVsuc1pU57RsoZNLtVlpYjc/4GsYYVrVDdHdjp65eCwSpIuWNskWBeQyqa1/6twrHczblV6+5/7fBXuuXCXhJfhU0tw9Dauq2wRN6wRN7xQ0rRM0u03QrE7Q7E5BhWmrTakzL5ezzZSxky0m+1mAxxpI+2OvHCs6I1cE6PAARXYFSi8fKHWS6oPyvaExAkrKfbuoLDK+OyQTXW8/MO9T6V2JAF2w1zmLHsljp4v5nbTTCu1sJ+2sQnubQbDRsPt1fSLXyjpGRfPvbO/b2Sqn4y5DmQ66VI2a9hyPNEyPbLrq6hmI4VPsz9mKJ3VHIru9wBamtamxdAgjgUMQQfNc1eT2QvFeoNWdsNTVOUyEoJLhbJGM5FcAWTqZSDnlwCs34NnRE9XuAXVQ2MpaZjLlUuzErtmbX349u+9WBGvP+GQg4Jb2/vS338921v7WUlXL7Ea/9oCKFWxSQf8b21KHg24388MwenOv1heR0Z0doFHp/Qst6nbj89s61Lq+85a2lhZgj8WKs25ZyAn0AeFGxNlRAPnTml9ge4nnLTG/hjpoA5io63mDgZW0V++5xID++ku3ozTVF5cBnmCDp4Eu9BLYsGTNw5CJTRJAT2KLpOd4JANhjCcq9sip7OsZhYOl0UZ4eFIdXufET/EMK4HleQqABxJ+QTuNPhCMVCz9rafXA32xVqEl4ljG84arWZwqTFAoXq4DRcLP9XqIjglQCW2M5bJLXvKc/bTh0IqxfyPaJD59voFlYvNOmJWtjYi+IxCbvGBgC8kR64jWhKyI3XwzxJN/eNt+Cf8cMu6GIlqqFTy9eJEmMkxzVO/wBVQ6n4LPe0BqOKZEjOEIsnLbJmhudkxnLQT6ViadIpObcmTQ/QVhvY3QWsE5HqujdSBFxAIcKYF8qCtak8f1+QLB5hATniTbtU5NmNwovyXbzUYm+oQes2glWREXmq4Ngtw9GW7XEXgHBjwnuxbpwT18q46bHTjdZdkSxQ0KSoikIrtArmG4MVJpQk6B4mEXDmr6yuEWYawD+gRV+kBkTe6QHo7haWyHjoTHEvPGpzlYqsFemPGv9LWEvTgiJ3iZOQ9MOjpK6dF7cg5DE+YNEmpdprBZ2hAApUF4wP5L6r+0gyiAho6ONL5F9qkAh9Wsq05afkYjoyp6c0r02dCY3SApp8536WErHrGypsn2uCQZij3tu9kWHkSJzmq0NT/Xx23F0zbPkzGd7NqNo3pXRlPNCSrkOntrVXd86pbdpu5o9+Fbjem/qjWvkuSTzcruWkiB+Qoape126T5aizF9R8osvm4ol815o37Dq6nCtU7WUcDEmiExLZh1Vj21d9JD4nxKg+ozTWS07ev4lefnaMxEpskrK/3OtyEY7TJIgkUoKvYpHfvnTbNAjOxaF3gFAuB82KxELHJA+kGisMoG2kXixtBwbhPQqGcytiYy+u3ufqHHte1KfUfd6nbdge1O7kFi1cqaFnP7rBfcTFHWqu1Vi60ogl2fLPJXeuOYtYblO4PiPQDNze4wP57mbgCwVKed/eTtVJ+p20j6eMq8FSKROLmuZFfJllVPsFFB+R3qu0SDzUUkvQu8B4Z49i6yZrJw4iZluOB4KOFLb4vx6S6F+iWkUP35+tRHX9c0NhDK3KnsNHdDSSbFsbz3snyvZUZ8TevNFMqXFbnja578+SV6F0uoEyF2cdpeLg+X9MiSLa7gzwVkvUu88shrRCxyhMl2kXhxsBDNXQjvvSxn6XzPOm9Uej0I8wBT73IZml7LTLLXGNa+zIedGaIYzXbtYNyae7v0EK/0JQaZmD5s2LH23euu1dMAkQMBPPToOAN4d6OQ7mF1N4aAkwml2iCAoVsZY/ztM/oC4CRi4oqvN2HaedOOZztP2ldsZYWtQnmbmTcOiM/prksmzjxwLR7kL5nS+KaGVn+HkTa9la3SbImVC0WI43n0tZtE9Anxa7sT+G84GXc7g2F3gNf8WEG3R6PBeNib9HvjbrvXHfYc1sLX7d5k0uuPuqPxcNQbDPsjoHawudDDOKvdnozaw95o0J8MHct/PJyMOt3BuNfta/6dwWAAlN1xu9sZd7rdYcqIxPQ7HZA06PW743532O0PjXyY1hkP+91Ot9/u9SejVMJkPOp0ur1ep9PvZTr12u4IVgAjw864PWp3YKNF+nG3O2qPJ8N+rz/WnAeTUb8/GI/bk0m/CwtxWGcefUYX2d/HXDuPqt7XcBqHiboOxTEK+ylYb2Ss2DYOm667rwS4EjYJ+4utdwF28RJzLfYfmwaN7y8gXy7pxv+AxcsFb/a7oKb503bH1tE33EdnOGD9zZV5tQD/EHFLb4LZwE1BTBBBiWOF0R0BuFqLh8EyOmDrwPdDUZTQUnJzwLqpFPt6IZWS62wExBzuWwAO/eCSBf5RzWdfzAuh14ERrAw+BP9AqBwf7gN9YVooaXv+EzQMof8AklXn+I1+6bru4T48Vmel2wXZ4FBhMjrWah+qhfSvj232OFTxcZaND5Wfe4Jn+33B9UYAW/0EqkPu4K0F7De4sDDwLg6KaQgEYy11uK9n5CXsF0Q8QmBdrjnWhTmmqLtkw0N8TxR+K1zSP4yfPgwvnAveBYX2UIOEtxLexUJelbHA1wJCpGZzeeDK39h7Y9Y0HwbtfZWmMW6toCY08fDUggyDD/wKHvTvRIkNPFBG65TWQ4XYASveXdPLj7RhHbBnJOxZYXllFZS4wiIggaBCqe27hTwcLXOv/m3AmmRYTe4LVf5i/6mQymQ8GKjf9cd/zbX+6uAxKHUHGUz6d4bTDpTyXzw8GUx5IQ/GKa/Em+LlwANTT/Urge8Mfs1nCk9lgqqoBxui+g3Fj4Zt+v1gm3472GY/GrbZ94Ntdk/YbqkT7EcYj0Atg6w3zEG2A6/0s48ngymV8GCnsqhMvzsq0ydHZfpoVGbfHZXZk6Py+Eiiby8eFUY6xZjS9V65x37N8UTgaPYP9hdCZPoDEJk+LSLTxyEy+wGIzJ4WkftFD/xMzwLgtzkksKcJ/wc

[javagl]

@huynhphanson Just curious: I know that the sandcastle does not yet work for all tilesets (e.g. ones that use RTC_CENTER won't work). But does the ❤️ mean that it helped to resolve the issue in this specific case?
(And I still wonder where the exact orientation and alignment came from in the three.js based visualization..)

[huynhphanson]

@javagl
I reacted with the ❤️ because I plan to experiment with the mesh.primitive approach. At the moment, I still haven’t managed to convert a GLB into a tileset.json that keeps the correct real-world coordinates.

The original model was created in Autodesk Civil 3D, then exported to IFC, and converted into GLB with IfcConvert. For this project the coordinate system is EPSG:9217. When loading the GLB into my Three.js application, I don’t modify the coordinates inside the model — I simply convert each model step by step from the local EPSG:9217 system into WGS84/ECEF so that everything can be positioned correctly in the real world.

[javagl]

OK, some aspects here (e.g. the details of the coordinate conversions in the chain of tools and conversions from Civil3D->IFC->IfcConvert) are a bit over my head. It sounds like the actual geo-location is eventually encoded in the GLB then. Iff this is the case, then it may pose challenges for the createTilesetJson command, because this command assumes that the glTF/GLB file is located "at the origin". However, if you have further details, insights, or qustions, just drop them here.