Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Changes to Khronos-TextureTransformMultiTest? #41

Open
bhouston opened this issue Oct 27, 2023 · 3 comments · May be fixed by #113
Open

Changes to Khronos-TextureTransformMultiTest? #41

bhouston opened this issue Oct 27, 2023 · 3 comments · May be fixed by #113

Comments

@bhouston
Copy link

bhouston commented Oct 27, 2023 •
edited

I noticed that the render fidelity test framework produces different results for Khronos-textureTransformMultiTest when one uses the model in this repo as compared to the one if the previous glTF-SampleModels repo?

The issue is with clear coat normals.

On the left is Three.js render of glTF-Sample-Models, and the right is using it from glTF-SampleAssets:

Screenshot 2023-10-25 at 9 37 15 AM

I also noticed that the Filament engine has similar issues (glTF-Sample-Model on the left, Sample-Aseets on the right):

Screenshot 2023-10-25 at 9 43 41 AM

Other render engines (Babylon.js, gltf-model-viewer) do not have differences.

I figure it must be because of normal reference frame code?

Did someone change the Khronos-TextureTransformMultiTest model in the migration to this repo?

I first noticed the issue here: google/model-viewer#4534 (comment)
@emackey
Copy link
Member

emackey commented Nov 17, 2023 •
edited

This is my model, but I'm not the one who changed it between repos.

A quick binary compare of old-vs-new shows that the TestMap_Normal.png file has changed, and in particular the old one falsely claimed to be sRGB colorspace in the header, and the new one does not specify that. This is likely a correction to the model.

Note however, this should make no difference to your renders! The glTF spec requires that colorspace information from PNG files be ignored, in favor of taking the colorspace as directed by glTF spec itself (which would be linear for a non-color image like this one). WebGL 1.0 may not be able to abide by this rule, but newer rendering systems should be capable.

See for example: TextureLinearInterpolationTest

So, my guess is that ThreeJS and Filament are not respecting glTF's choice of colorspace, creating this diff, but BabylonJS and the Khronos Sample Viewer are handling it correctly (with no diff).

@lexaknyazev
Copy link
Member

WebGL 1.0 may not be able to abide by this rule, but newer rendering systems should be capable.

Both WebGL versions support setting this state via gl.pixelStorei(gl.UNPACK_COLORSPACE_CONVERSION_WEBGL, gl. NONE) command.

@lexaknyazev
Copy link
Member

The root cause here is that this repo uses an old version of this asset. The normal map has been updated in KhronosGroup/glTF-Sample-Models#365 and KhronosGroup/glTF-Sample-Models#367.

@lexaknyazev lexaknyazev mentioned this issue Nov 24, 2023
Closed
This was referenced Mar 19, 2024
Open
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Update TextureTransformMultiTest normal maps javagl/glTF-Sample-Assets
3 participants
@bhouston @emackey @lexaknyazev