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

Cesium ion
1

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?

2

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

3

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
chrome_u8k3OuPqUe2296×722 68.6 KB

6

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? 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.

7

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.

8

@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.

10

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!

11

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 (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).

14

@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:

{
    "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.

15

Hi @flav,

Yes, feel free to email the model to me at 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!

1 Like
16

The part

"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 :crossed_fingers:

17

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. 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

1 Like
18

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.

19

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 . 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

20

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?

21

To check the bounding volumes, I used this CesiumJS Sandcastle. 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:

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.

1 Like
22

@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.

1 Like