Inconsistent shadows on different GLTF models

1. A concise explanation of the problem you’re experiencing.

These 2 models are pretty much side by side and the camera is looking the same direction with shadows on and the time slider at exactly the same paused time. They were both exported from Sketchup as DAE with the same exact options and no light sources, then run through COLLADA2GLTF and uploaded to Ion. One thing that is different is that house #1 (Ion asset #16185) has a -90 heading and house #2 (Ion asset #16849) has a 0 heading.

The camera is facing north and the trees are casting shadows NE, which is intended. House #1 is illuminated by the sun from the SW and the shadows are cast NE as expected. House #2 shows it being absolutely pitch black on the S side of the house and ultra-bright on the N side, which is downright bizarre. Would rotating models in Ion be causing the wrong shading to be streamed?

So basically, the light source for house #2 seems to be moving in a totally different (and incorrect) direction than the light source for house #1, as if there are two suns, one for each house. I’ve noticed this with about 1/3rd of the models I run through GLTF that are sitting in Ion. I’m not sure if its a COLLADA2GLTF issue or an Ion issue, but it seems like its related to rotation in some way shape or form.

2. A minimal code example. If you’ve found a bug, this helps us reproduce and repair it.

Don’t know if code on the front-end is involved here.

3. Context. Why do you need to do this? We might know a better way to accomplish your goal.

Just want these two houses to illuminate the same way. This is a 3-D landscape of a historic scene.

4. The Cesium version you’re using, your operating system and browser.

1.54, Chrome 72.

As a test I just rotated house #2 90 degrees, and now the lighting is more accurate. It seems that Ion shades the 3dtiles the same no matter the rotation, so I guess i’m wondering if there is a way to “re-render” the shading after I’ve rotated the model. It seems like for me to change that, I’d have to open the model in Sketchup and manually rotate it all and then re-export and run it through that pipeline again.

In the above picture, I placed a copy of the model 50 yards west, instantiating locally with a heading of 0, next to the 3dTiles version, which is interestingly rotated -90, even though as you can see, in the end, the model is in the same orientation, but with completely different shading too. When I turn on shadows, the local copy of the model renders exactly as expected, but the 3DTiles one is a little bit different…not even 90-degrees different, but just some unknown angle.

So in short:

  1. Do 3Dtiles in Ion get shading rendered first, and then rotating the model in Ion just rotates the already-exported time-dependent shading?
  2. Is there a way to have the time-dependent shading be re-rendered after “rotating” them in Ion’s UI?
  3. Is it expected that the model uploads into Ion in a different natural rotation despite it being the same GLTF?
  4. Is there a way to make the 3Dtiled model shade/illuminate the same way as the one I have uploaded locally?
    Pardon me if I have the wrong idea about how 3Dtiles’ pipeline works in terms of shading.

You are correct in that the shading is not baked in, so this is strange. I wasn’t able to reproduce this with a quick test model. This might be a bug. Can you share a Sandcastle with an access token that has access to just those two assets?

When you tiled this, you uploaded a glTF, and you selected “BIM/CAD/Other” right?

Zoom out and you’ll see what I mean.

These are two tilesets, right next to each other, and the only difference in that for one tileset, I changed the heading to -180 on the Ion “Adjust Tileset Location” slider. As you can see, the shading is static. The shading seems to be “baked in” based on however the model was oriented upon upload. Can we have this re-shade when I change the position sliders in Ion?

I can only change the shading by opening the model in Sketchup, rotating it 180 on the 0,0 axes, saving it, COLLADA2GLTFing it, and re-uploading to Ion.

Would you agree that shading ought to be based on positioning? The north side should be brighter than the south side on both of them. And that’s exactly how models work when you add them locally to viewer.entities. Instead, the shading was only performed once, with no regard to how I adjusted the heading slider in Ion for the second tileset. So basically, the model textures are identical, despite them being oriented in the opposite direction. So the end result makes your head hurt because it looks like each has a separate light source.

When you tiled this, you uploaded a glTF, and you selected “BIM/CAD/Other” right?


Yeah I think we’ve found a bug here. When ion converts the glTF to 3D Tiles it takes any node transformations and applies them to the geometry, so that materials can be batched between models. So it looks like the vertices are transformed, but the normals might not be.

We’re looking into it. Just to confirm though, can you share the glTF you get out of the Collada2Gltf conversion? I would expect it to have a rotation transform on the root node.

I’m wondering if there’s anything obviously abnormal about those GLTFs. Do you guys have an ‘issue’ for this in Github that I could track by chance?

There is an issue on the ion tiling backend which is private. It definitely is a bug on our end though. This will happen with any glTF that has a transformation matrix on the root node (or any node too?)

I think the reason it wasn’t caught for a long time is because the tiling pipeline was initially created just for photogrammetry, which are typically unlit models.

Good to know, thanks!

Hey Gibran,

We’ve just shipped a fix for this! Can you try again and confirm it works?

If I change nothing, the problem remains (that shed is rendered correctly and is instantiated locally, the house is an 3D tileset added several weeks ago).

Re-uploaded the GLTF, and…

Voila. Thank you so much, Omar! I need to clean up my Ion asset repository anyway so I’ll re-upload. :slight_smile: