Texture Issue with Google Photorealistic Tiles

Hello! I’ve been able to get my application working with the Google Photorealistic Tiles using the Raster Overlay (Imagery asset).
HOWEVER, now I’m reading the textures that are streamed alongside the model (the images in the CesiumGltf::Model), and the textures look wrong on the mesh. Here’s what it looks like:

If this looks like a familiar visual bug to anyone PLEASE LET ME KNOW!

All I’m doing in my code is reading the CesiumGltf::ImageAsset that is associated to the texture, and reading the uvs as I did before (but using the TEXCOORD_0 attribute channel).
One difference with the raster is that I’m using the scale and translation params passed to attachRasterInMainThread, but with the gltf model texture I do not access these params (I don’t how to), so I just them to a default (scale = (1,1), translation = (0,0,0)).

If you need to see any code, I can post it.

Hi @Nathalie_Raffray, welcome to the community!

Based on the classes you’re referencing, it sounds like you’re using cesium-native to build your application, so I’ve moved this to the appropriate category. But please let me know if that’s incorrect!

I’m not sure what could be wrong from a glance, but it would help to see how you’re reading the textures in your material / shader. If you output TEXCOORD_0 in the red/green channel of the frag shader, you could compare how it looks in another runtime (like Unreal, Unity) and catch any glaring differences.

If the UVs look the same, then perhaps check that the sampler parameters are being correctly set on the textures, or that the textures are being written correctly to your engine. One thing that we realized in Unity was that (0,0) is the bottom left corner of a texture in Unity, whereas in glTF it is the top left corner. Perhaps that’s coming into play here?

Hi @janine,

The issue was indeed the fact that glTF considers uv=[0,0] to be the top left and our engine considers uv=[0,0] to be bottom left. I just did v=1-v and it fixed it.

Thank you so much!