GLTF EXT_lights_image_based cubemap orientation

I am testing a gltf file in the sandbox that uses the EXT_lights_image_based (glTF/extensions/2.0/Vendor/EXT_lights_image_based at master · KhronosGroup/glTF · GitHub) extension and I’m seeing the cube faces end up in incorrect places when rendered with Babylon. The image-based lighting reflected in an object shows that the flattened cubemap, as shown in the spec (glTF/extensions/2.0/Vendor/EXT_lights_image_based at master · KhronosGroup/glTF · GitHub), is folded up such that Face 3 (-Y) is on the top and Face 2 (+Y) is on bottom. Additionally, I’m also noticing that the skybox that gets created is also inverted, though it has the Z instead of Y directions incorrect. I’m also curious why the skybox is added at all.

These are incorrect, right?

Edit: Somewhat different issue, but I’m also seeing a rotation discrepancy in the image based lighting between the sandbox (4.1.0-beta.23) and the Babylon previewer in VS Code (4.0.3). One appears to be using leftHanded rotation, the other right handed. Would using Babylon through these different systems have different defaults? I’m also seeing fairly different behavior between the two versions for irradiance.

Adding @bghgary our GLTF master.

I’m investigating…

Sorry for the delay.

I found an issue where the skybox and the reflection texture on the model were different. The skybox was applying it’s reflection matrix twice and we have fixed this problem.

Here is the test model I’ve been using: (329.5 KB)
I will put this up on GitHub after I clean it up a bit. I purposefully changed the IBL rotation to rotate around Y by 180 degrees.

As for your specific issue, can you attach the model you are using? The zip I sent above should match what the spec says.

I tried a few models and didn’t see any differences. The sandbox uses left-handed and vscode uses right-handed, but there should be no visible difference.

I believe I’ve figured out the main issue. The rotation quaternion in my gltf was of the form [scalar, …vector], while the extension takes […vector, scalar]. I should have known from the 1 in the default value for rotation that this was the order. It may help if the extension’s documentation is updated to explicitly state the intended quaternion order. Anyways, thanks for looking into the issue and providing your example environment, it was quite helpful.

1 Like

All quaternions in glTF follow the info here:glTF/specification/2.0 at master · KhronosGroup/glTF · GitHub.

rotation: A quaternion (x, y, z, w), where w is the scalar

If you think it will be useful to link to this (or repeat the information) in the extension, maybe open a PR?

1 Like