# Does uploading a 3d tile to Ion change the mesh at all?

**URL:** <https://community.cesium.com/t/does-uploading-a-3d-tile-to-ion-change-the-mesh-at-all/39058>\
**Category:** Cesium ion\
**Created:** [March 4, 2025, 11:48pm UTC](https://community.cesium.com/t/does-uploading-a-3d-tile-to-ion-change-the-mesh-at-all/39058 "2025-03-04T23:48:18Z")\
**Posts on this page:** 17\
**Page:** 1

<div class="post-metadata">

**Author:** ![flav](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/flav/32/21649_2.png) [@flav](https://community.cesium.com/u/flav)\
**Post date:** [March 4, 2025, 11:48pm UTC](https://community.cesium.com/t/does-uploading-a-3d-tile-to-ion-change-the-mesh-at-all/39058/1 "2025-03-04T23:48:18Z")

</div>

I have a 3d tile that contains a sort of hierarchical lod and uses implicit tiling. I’m manually creating the mesh and subdividing it into a quad tree. Each piece of this quadtree is a glb with specific uvs. After uploading this tileset to ion, and streaming it to Unreal, those mesheshave different uvs from the ones I created and my texturing goes wrong. I can verify this by loading the glb into Unreal manually to see the correct uvs, but once it comes through from Ion it’s different.

Am I missing something obvious about how this is handled when going through Ion?

---

<div class="post-metadata">

**Author:** ![mdc9001](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/mdc9001/32/15919_2.png) [@mdc9001](https://community.cesium.com/u/mdc9001)\
**Post date:** [March 5, 2025, 4:35pm UTC](https://community.cesium.com/t/does-uploading-a-3d-tile-to-ion-change-the-mesh-at-all/39058/2 "2025-03-05T16:35:25Z")

</div>

Hi,

If you uploaded it as 3D Tiles, ion should just host the data as is. However it is possible that during the upload one of the settings was not correct and ion treated it as set of GLB files and tiled them.

Do you have an asset id so that we can look into this further?

Regards,

Mark

---

<div class="post-metadata">

**Author:** ![flav](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/flav/32/21649_2.png) [@flav](https://community.cesium.com/u/flav)\
**Post date:** [March 5, 2025, 8:41pm UTC](https://community.cesium.com/t/does-uploading-a-3d-tile-to-ion-change-the-mesh-at-all/39058/3 "2025-03-05T20:41:06Z")

</div>

Hey Mark, thank you for your reply!

I’m afraid I can’t share the data as it’s self-hosted.

I believe it should have treated it as a 3d tile though, there’s not many options available from what I can see.

 ![chrome_u8k3OuPqUe](https://global.discourse-cdn.com/cesium/original/3X/2/a/2a4fbe300cebca7b7f164683090ba085e393194b.png)

---

<div class="post-metadata">

**Author:** ![mdc9001](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/mdc9001/32/15919_2.png) [@mdc9001](https://community.cesium.com/u/mdc9001)\
**Post date:** [March 6, 2025, 3:43pm UTC](https://community.cesium.com/t/does-uploading-a-3d-tile-to-ion-change-the-mesh-at-all/39058/6 "2025-03-06T15:43:45Z")

</div>

Yes, those are the correct settings for uploading the data as a 3D Tileset.

Are you able to try [loading a local copy of the 3D Tileset into Unreal?](https://cesium.com/learn/unreal/unreal-faq/#how-do-i-load-tilesets-offline) That would help narrow down if it is something with ion or how Cesium for Unreal is handling the GLBs.

I’ve also reached out to our Unreal team to see if they have any suggestions.

---

<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:** [March 6, 2025, 4:35pm UTC](https://community.cesium.com/t/does-uploading-a-3d-tile-to-ion-change-the-mesh-at-all/39058/7 "2025-03-06T16:35:30Z")

</div>

Another diagnosis step could be to compare the _uploaded_ GLB and the corresponding _downloaded_ GLB. To my understanding, these should be identical. If they are not, then one can look at what the differences are, and narrow down which of them might cause the wrong texturing.

---

<div class="post-metadata">

**Author:** ![flav](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/flav/32/21649_2.png) [@flav](https://community.cesium.com/u/flav)\
**Post date:** [March 10, 2025, 10:03pm UTC](https://community.cesium.com/t/does-uploading-a-3d-tile-to-ion-change-the-mesh-at-all/39058/8 "2025-03-10T22:03:47Z")

</div>

@mdc9001 @Marco13, thank you both for the suggestions! It has helped me dive into this a bit more. So, I see the issue when I load the tileset locally as well, bypassing Ion, meaning it’s not Ion modifying anything.

I still only see the issue when rendering the mesh as part of the tileset and not if I load the same glb as a static mesh into Unreal, so the search continues. I’ll look a bit closer at what’s happening between loading a tileset and rendering that mesh now, in case that points to anything specific.

---

<div class="post-metadata">

**Author:** ![janine](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/janine/32/5135_2.png) [@janine](https://community.cesium.com/u/janine)\
**Post date:** [March 11, 2025, 3:09pm UTC](https://community.cesium.com/t/does-uploading-a-3d-tile-to-ion-change-the-mesh-at-all/39058/10 "2025-03-11T15:09:21Z")

</div>

Hi @flav!

I work on Cesium for Unreal – just trying to catch up on what’s going on here. If you’re able to share a test model that results in the same behavior, then we could try to reproduce this on our side and hopefully diagnose the issue.

Do you recall tiling your data with any specific settings? For example, Draco compression? It’s possible that there is a bug when trying to decompress the tileset at runtime. It would also be good to confirm that you’re able to view your tileset correctly in the Cesium ion preview (which is built on CesiumJS). That way we can isolate it as an Unreal bug, and not a tilers one.

Thanks!

---

<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:** [March 11, 2025, 3:15pm UTC](https://community.cesium.com/t/does-uploading-a-3d-tile-to-ion-change-the-mesh-at-all/39058/11 "2025-03-11T15:15:22Z")

</div>

When encountering ~“unexpected rendering behavior”, it often makes sense to to make sure that the GLB/glTF files are _valid_, by checking them with the [glTF Validator](https://github.khronos.org/glTF-Validator/) (or, for a whole tileset at once, with the 3D Tiles Validator).

Assuming that they _are_ valid, the validator may still provide some helpful information. Specifically, whether the GLBs use any form of compression (like the Draco compression that Janine mentioned, or maybe meshopt), or any other extension that may affect the texture display (like `KHR_texture_transform`).

---

<div class="post-metadata">

**Author:** ![flav](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/flav/32/21649_2.png) [@flav](https://community.cesium.com/u/flav)\
**Post date:** [March 11, 2025, 3:51pm UTC](https://community.cesium.com/t/does-uploading-a-3d-tile-to-ion-change-the-mesh-at-all/39058/14 "2025-03-11T15:51:13Z")

</div>

@janine Thank you for your reply. Would it be possible to email this data instead of making public?

There’s no draco compression, the 3d tile is created manually and has a tileset.json, a subtree.json, and all the glb for all lods and all parts of each lod (it’s essentially a hierarchical lod using implicit tiling). This is the folder i upload to Ion (or load locally).

The mesh renders fine in both Ion and Unreal Engine, it’s just the UVs on everything other than the lowest lod (i.e. everything that’s split into more than one mesh) that seem to be broken. Unfortunately it’s not trivial to verify with Ion as a test because as it stands, the tile itself doesn’t have any textures. In both Ion and Unreal it just displays as black by default until a material is added, making it difficult to verify if the UVs are correct or not in Ion.

@Marco13 all glbs show up as green in the glTF validator and there’s no errors reported by the 3d tileset validator either. Here’s an example of the validator for one of the glbs:

```auto
{
    "uri": "0.glb",
    "mimeType": "model/gltf-binary",
    "validatorVersion": "2.0.0-dev.3.10",
    "validatedAt": "2025-03-11T15:44:17.869Z",
    "issues": {
        "numErrors": 0,
        "numWarnings": 0,
        "numInfos": 2,
        "numHints": 0,
        "messages": [
            {
                "code": "UNUSED_MESH_TANGENT",
                "message": "Tangents are not used because the material has no normal texture.",
                "severity": 2,
                "pointer": "/meshes/0/primitives/0/attributes/TANGENT"
            },
            {
                "code": "UNUSED_OBJECT",
                "message": "This object may be unused.",
                "severity": 2,
                "pointer": "/meshes/0/primitives/0/attributes/TEXCOORD_0"
            }
        ],
        "truncated": false
    },
    "info": {
        "version": "2.0",
        "generator": "Houdini GLTF 2.0 Exporter",
        "resources": [
            {
                "pointer": "/buffers/0",
                "mimeType": "application/gltf-buffer",
                "storage": "glb",
                "byteLength": 357164
            }
        ],
        "animationCount": 0,
        "materialCount": 0,
        "hasMorphTargets": false,
        "hasSkins": false,
        "hasTextures": false,
        "hasDefaultScene": true,
        "drawCallCount": 1,
        "totalVertexCount": 5169,
        "totalTriangleCount": 7837,
        "maxUVs": 1,
        "maxInfluences": 0,
        "maxAttributes": 5
    }
}

```

I assume the two infos shouldn’t cause any issues.

Please note, if I just import this glb as a static mesh into Unreal, it shows the UVs I expect. It only seems to render with bad UVs when loaded and rendered as part of a 3d tile.

Since I can reproduce this when loading the 3d tile from a local URL as well, we can likely safely assume it’s not caused in any way by Ion anymore, which means this thread is probably in the wrong subforum now. Apologies.

---

<div class="post-metadata">

**Author:** ![janine](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/janine/32/5135_2.png) [@janine](https://community.cesium.com/u/janine)\
**Post date:** [March 11, 2025, 9:09pm UTC](https://community.cesium.com/t/does-uploading-a-3d-tile-to-ion-change-the-mesh-at-all/39058/15 "2025-03-11T21:09:08Z")

</div>

Hi @flav,

Yes, feel free to email the model to me at [janine@cesium.com](mailto:janine@cesium.com). I plan to test the model by itself, as well as with Cesium ion’s tilers to see if that makes a difference. If there’s something else I should try, let me know!

---

<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:** [March 12, 2025, 1:55am UTC](https://community.cesium.com/t/does-uploading-a-3d-tile-to-ion-change-the-mesh-at-all/39058/16 "2025-03-12T01:55:10Z")

</div>

The part

```auto
"code": "UNUSED_OBJECT",
"message": "This object may be unused.",
"severity": 2,
"pointer": "/meshes/0/primitives/0/attributes/TEXCOORD_0"

```

looks at least suspicious when you say that there is an issue with the texture coordinates. But as far as I understood the description, the goal seems to (roughly) be to load this _without_ textures (and the “unused” texture coordinates), but then _assign_ a texture in Unreal (that should _use_ these texture coordinates)

This touches some details of Unreal that I’m not familiar with - namely, how the texture coordinates from the mesh are wired together with the material that is assigned within Unreal. So until now, I could only make guesses. Maybe some part of the process that converts the GLB into an ‘Unreal Mesh’ _omits_ the texture coordinates, because it realizes that they are unused? That wouldn’t explain why it works when it’s imported manually, though. Hopefully, the issue can be sorted out based on the actual data set 🤞

---

<div class="post-metadata">

**Author:** ![janine](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/janine/32/5135_2.png) [@janine](https://community.cesium.com/u/janine)\
**Post date:** [March 13, 2025, 4:26pm UTC](https://community.cesium.com/t/does-uploading-a-3d-tile-to-ion-change-the-mesh-at-all/39058/17 "2025-03-13T16:26:56Z")

</div>

Hi @flav,

Thanks for sending over the test data. I’m seeing the same visual bugs on my end, too.

I believe this is actually a problem that we previously observed here: [Buggy texture coordinate generation for raster overlays · Issue #1564 · CesiumGS/cesium-unreal · GitHub](https://github.com/CesiumGS/cesium-unreal/issues/1564). For context, when we drape raster overlays over 3D Tiles in Unreal, we generate a completely new set of texture coordinates to map the raster. It’s not using the original texture coordinates in the glTF, so that’s why you’re seeing correct UVs in one but different UVs in another. When I wrote that Github issue, I couldn’t confirm whether it was just a problem with the user’s own data. However, the fact that this came up again leads me to believe that there’s something genuinely wrong with how we drape raster overlays at runtime.

I’m going to escalate this as a bug to our team so that one of our members can take a closer look. We’ll update this thread when there’s progress. Thank you again!

Best regards,  
Janine

---

<div class="post-metadata">

**Author:** ![Kevin\_Ring](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/kevin_ring/32/2003_2.png) [@Kevin\_Ring](https://community.cesium.com/u/Kevin_Ring)\
**Post date:** [March 18, 2025, 1:07am UTC](https://community.cesium.com/t/does-uploading-a-3d-tile-to-ion-change-the-mesh-at-all/39058/18 "2025-03-18T01:07:54Z")

</div>

Hi @flav,

@janine passed your tileset along to me, and I took a look. The problem is that you’re using implicit tiling, but your tile content doesn’t match the expected implicitly-defined bounding volumes.

- Tile `content/1/0/0.glb` should cover the southwest quadrant of the root tile. Instead, it covers the northwest quadrant.
- Tile `content/1/1/0.glb` should cover the southeast quadrant of the root tile. Instead, it covers the southwest quadrant.
- Tile `content/1/0/1.glb` should cover the northwest quadrant of the root tile. Instead, it covers the northeast quadrant.
- Tile `content/1/1/1.glb` should cover the northeast quadrant of the root tile. Instead, it covers the southeast quadrant.

I didn’t look at any deeper levels, but it’s safe to say they have a similar problem.

Because the implicit bounding regions don’t match the tile content, and because the raster overlay texture coordinates are generated from the bounding region, the texture coordinates are incorrect for their content.

---

<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:** [March 18, 2025, 1:31pm UTC](https://community.cesium.com/t/does-uploading-a-3d-tile-to-ion-change-the-mesh-at-all/39058/19 "2025-03-18T13:31:28Z")

</div>

Just as a cross-link: This would be another form of the broader issue of “consistency between geometry and bounding volume declarations”, which was also the reason behind [Implicit tiling file format help - #8 by Marco13](https://community.cesium.com/t/implicit-tiling-file-format-help/38926/8) . I’ll consider these threads as aspects that increase the priority of [Validate that geometry is fully contained in bounding volumes · Issue #233 · CesiumGS/3d-tiles-validator · GitHub](https://github.com/CesiumGS/3d-tiles-validator/issues/233)

---

<div class="post-metadata">

**Author:** ![flav](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/flav/32/21649_2.png) [@flav](https://community.cesium.com/u/flav)\
**Post date:** [March 18, 2025, 4:46pm UTC](https://community.cesium.com/t/does-uploading-a-3d-tile-to-ion-change-the-mesh-at-all/39058/20 "2025-03-18T16:46:34Z")

</div>

Thank you @Kevin_Ring for looking into this. That’s an interesting manifestation of the issue. I updated my export so 0,0 is southwest corner, it was indeed transposed and an error in my export. Unfortunately I get the same UV errors with the new data. Is there any additional way to verify on my end that the geometry and its bounds is correct?

---

<div class="post-metadata">

**Author:** ![Kevin\_Ring](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/kevin_ring/32/2003_2.png) [@Kevin\_Ring](https://community.cesium.com/u/Kevin_Ring)\
**Post date:** [March 19, 2025, 3:36am UTC](https://community.cesium.com/t/does-uploading-a-3d-tile-to-ion-change-the-mesh-at-all/39058/21 "2025-03-19T03:36:26Z")

</div>

To check the bounding volumes, I used this [CesiumJS Sandcastle](https://sandcastle.cesium.com/#c=bZJhbxMxDIb/ilXx4Sp1SaeBNJWuQrRIIDGG2AAh3YelObcN5OJT4mvXTf3vJJfrGLCPdvw+fm1HSnjbGlsZt4ZKsQJNrWcMe6AVfPoxh6sG3SI9NORZ2QlsmJuJlLvd7lS4vRZr2spgGGVFhlkaZ9goNlsM8qw6WfZw0ag1lk6TCwxbgzv0cAEOdzDHYNpafOtyRTnQXTwnx8o49OVg+Lp0pcsagXeMrip6UU7m4GxxYyyGDy40qJn8pbkzLmlzT3PMp0aXVKGN/XuofhbQ0bvKzgD7PTyUDiDzONUiR4jaKcPHMf7ygixWnuqv3sa5+r1Z0spuKPDkfHw+lj1G/AzkysEodwBAp5YWF7hs19+Nx5VXNU6AfYujVHBIc8HRftDoUDTe1Kbbu1BVVfTgXHjsUiXgnCx5c4+dxeg/UbsJH4H3RPUNFdlKrx3l6MnF3qNKl/1sWG++KLfGYizGIzgZi1ejx45Lal2qum426FH4KGkDSHgpxsMOmQweQKsIgQK9Jz/8s2ayKCyti9t36QEsdR2P8Am8eOgUh9tMGYwG08B7i7NsFuCNqdO/hTaeQAjJWDdWxe8tl63+Fe3pEPKGAKbyqXRamS2Y6uKZ/wjaqhDiy6q19joushzMpjLW/yft/V5t0Vu1T2Wb09nHnBRCTGUMn1cykV0q/w/5Nw). Replace the URL with the URL of your tileset.json. If you don’t have a web server handy, you can get one easily with Node.js by running this in the directory containing your tileset.json:

```auto
npx http-server . -c-1 --cors

```

Then, in the Sandcastle, open up the “Tile Debug Labels” section of the 3D Tiles Inspector and click “Show Picked Only” and “Url”. Then you can try to hover over a tile to see which one it is. It’s fiddly because when CesiumJS tries to determine which tile your mouse is over, it first checks the tile’s bounding volume. So when your bounding volumes are wrong, it’s really hard to actually hover over a tile. You need to find a spot that is inside the (incorrect) bounding volume and also over a triangle for that tile. The edges of the tiles are your best bet. When you successfully hover over a tile, the tile’s triangles will become translucent and the filename of the tile will be displayed, so you can use this to check that the content matches the tiling scheme.

Normally you could simply turn on “Tile Debug Labels” and leave “Show Picked Only” off, and CesiumJS would draw a label over each tile with the tile’s filename. But it places the label based on the bounding volume, so it will be actively misleading in this case.

By the way, the texture coordinate problem is not the only manifestation of incorrect bounding volumes. You will also see tiles disappear unexpectedly with certain camera poses. The texture smearing is just the most obvious symptom.

---

<div class="post-metadata">

**Author:** ![flav](https://sea2.discourse-cdn.com/cesium/user_avatar/community.cesium.com/flav/32/21649_2.png) [@flav](https://community.cesium.com/u/flav)\
**Post date:** [March 19, 2025, 4:04pm UTC](https://community.cesium.com/t/does-uploading-a-3d-tile-to-ion-change-the-mesh-at-all/39058/22 "2025-03-19T16:04:38Z")

</div>

@Kevin_Ring thank you kindly for your help and suggestions, it has been very helpful. Everything works well now that the tiles are all in the right location and glbs have no errors.
