# Self made 3D tiles terrain, precision problem at edges problem

**URL:** <https://community.cesium.com/t/self-made-3d-tiles-terrain-precision-problem-at-edges-problem/38410>\
**Category:** 3D Tiles\
**Created:** [February 5, 2025, 12:08pm UTC](https://community.cesium.com/t/self-made-3d-tiles-terrain-precision-problem-at-edges-problem/38410 "2025-02-05T12:08:57Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![Marco13](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/marco13/32/2757_2.png) [@Marco13](https://community.cesium.com/u/Marco13)\
**Post date:** [February 10, 2025, 3:44pm UTC](https://community.cesium.com/t/self-made-3d-tiles-terrain-precision-problem-at-edges-problem/38410/8 "2025-02-10T15:44:24Z")

</div>

To emphasize my disclaimer:

> There are several building blocks and processing steps coming together here: The source data. The conversion. The representation within the glTF. The rendering engine. And at each point, precision _might_ be lost in one way or another. So it might be necessary to iterate on some of these points in order to find a suitable solution.

* * *

I’m not sure whether I fully understood all details of what you have been describing in the last posts. But **iff** I understood this correctly, then you are doing certain computations (for aligning the vertex positions) **within** Blender. (I’m not a Blender expert - is this some sort of “script” that can be run in Blender itself? Or some sort of ~“Python-based ‘Plugin’ for Blender” that you created just for this purpose?)

Looking at the `node.translation` of `[4200249.74042291,2793613.93061088, 3880785.3615384]` in the JSON that you posted, it might very well be that this large translation causes trouble here. (Maybe some of this could even be caused for `double` when something like a [cancellation](https://en.wikipedia.org/wiki/Catastrophic_cancellation#In_numerical_algorithms) is happening somewhere - some guesses are involved here…)

Specifically, you mentioned

> … the process is simply summation of _mesh.translation(Center) + local vertex value (double + float)_ . (or, is it?)

I don’t know for sure. But it might be that Blender is doing some computation or storage here in single-precision `float`.

Even at the risk that this appears to be a bit of trial-and-error (with the goal of not really _avoiding_ but just _minimizing_ the error…):

You could try to _not_ store the `node.translation` in the glTF at all. Instead, you could apply this translation as part of the `tile.transform` within the tileset JSON.

This may have two advantages:

- The resulting glTF could be in its canonical form: At the origin, with y-up. (I tried to [illustrate](https://community.cesium.com/t/from-i3dm-to-ext-mesh-gpu-instancing/19731/11) this advantage in an otherwise unrelated thread
- More important here: All the computations that you are doing there do no longer involve these “huge” numbers. They can all happen in this “local, small glTF”. (And the glTF is only moved to the right position eventually, with the 3D Tiles `transform`)

---

_[View the full topic](https://community.cesium.com/t/self-made-3d-tiles-terrain-precision-problem-at-edges-problem/38410)._