Adding KHR_materials_retroreflection example

[mklefrancois]

This sample asset accompanies KhronosGroup/glTF#2610, which proposes the KHR_materials_retroreflection extension.

The scene contains two traffic cones side by side: one with a retroreflective material using both retroreflectionFactor and retroreflectionTexture, and one without the extension for comparison. The retroreflective cone brightens significantly when the light and camera directions are closely aligned, which is the characteristic appearance of real-world retroreflective materials such as high-visibility clothing and road markings.

Rendered with vk_gltf_renderer.

[echadwick-dgg3d]

This is a great example!

I think it needs a few changes, per SubmittingModels:

• The .glTF JSON file should be named with PascaleCase to match the folder name
• The glTF asset and its resources should be moved into a \glTF subfolder (Models/TrafficCone/glTF/TrafficCone.gltf).
• It's missing a README.md with a screenshot folder.
• It's missing properly formatted license and metadata files.

You can check one of the existing assets to see how things are ideally set up.

[mklefrancois]

Thanks @echadwick-dgg3d, I made many changes and hopefully it meets all requirements.

[echadwick-dgg3d]

Looking good. One discrepancy, the readme says the screenshot is from the sample viewer, but the image shows evidence of pathtracing (shadows & soft reflections on the ground plane) which the viewer does not support. Which renderer was it created with? I think it's ok if it's not the glTF Sample Viewer, since we do have other assets with pathtraced screenshots.

[mklefrancois]

Thanks for pointing it out, I took another model as template and forgot to modify this. The renderer is vk_gltf_renderer. Updating the readme.

[echadwick-dgg3d]

A couple more points I noticed:

Is there a reason why the two materials use "metallicFactor": 0.5,? Any metallic values which are not 0 or 1 are non-physical in the metallic-roughness shading model, so this can lead to unpredictable behavior in renderers. The general advice is to only use grays for anti-aliasing in a metallic texture.

Also, the two gray textures ConeBaseMat_metallicRoughness.png and ConeBaseMat_retroreflective.png could ideally be 8bit grayscale format instead of 24bit.

[mklefrancois]

Thanks @echadwick-dgg3d, good catches. Fixed both.

Setting metallic to 0 like you suggested actually made the retroreflection almost disappear. It makes sense once you look at the MRM model (Portsmouth et al.): the retroreflection is basically the specular lobe bounced back toward the light, so its strength comes from the specular reflectance. That metallicFactor: 0.5 was faking that reflectance — exactly the non-physical trick you flagged. On a proper dielectric (F0 ≈ 0.04) there's almost nothing left to bounce back.

So instead of cheating with metallic, I gave the tape a real dielectric specular via KHR_materials_specular (masked to the stripes). The paper actually calls for this — it says F for retroreflectors should be treated as an empirical value rather than a smooth-surface Fresnel, since the real tape scatters through glass beads / corner cubes.

For the textures: both are 8-bit grayscale now (~55% smaller). They were also identical, so I merged them into one image and dropped the duplicate (metallic-roughness reads G/B, retroreflection reads R).

The two materials are now identical; the only difference is the KHR_materials_retroreflection extension on the left one.

[echadwick-dgg3d]

Setting metallic to 0 like you suggested actually made the retroreflection almost disappear. It makes sense once you look at the MRM model (Portsmouth et al.): the retroreflection is basically the specular lobe bounced back toward the light, so its strength comes from the specular reflectance. That metallicFactor: 0.5 was faking that reflectance — exactly the non-physical trick you flagged. On a proper dielectric (F0 ≈ 0.04) there's almost nothing left to bounce back.

So instead of cheating with metallic, I gave the tape a real dielectric specular via KHR_materials_specular (masked to the stripes). The paper actually calls for this — it says F for retroreflectors should be treated as an empirical value rather than a smooth-surface Fresnel, since the real tape scatters through glass beads / corner cubes.

Awesome (though I don't think I advised setting it to zero). Could you add your info in the readme, so people can learn why it's needed and how they can reproduce this effect with their own assets?

Does the readme need to be updated to list the specular extension?

Have you run this asset through the glTF Validator? I think there might be an unused texcoord on the floor, but this is a pretty minor issue I think.

It might seem like a lot of work to get something into the repo, but it's worth the effort to have a bunch of well-formed assets. Thanks for all your work on this!

[mklefrancois]

Thanks! I really appreciate the thorough review and attention to details. This will help when we will bring the asset for opacity micromaps!

And you're right — the "set to 0" was my call; you said 0 or 1, and 0 is the physical one for a plastic cone.

Added a Materials section to the README explaining why KHR_materials_specular is needed — retroreflection redirects the specular lobe, so a plain dielectric (F0 ≈ 0.04) makes it barely visible.

The extensions are automatically added by the script. I have regenerated it, and KHR_materials_specular, KHR_lights_punctual now appears to the extensions list.

Good catch on the floor — an unused TEXCOORD_0 (the plane material has no textures), so I removed it and its orphaned accessor/bufferView. Ran it through the glTF Validator: 0 errors, 0 warnings. The only remaining message is an info that the validator doesn't yet know KHR_materials_retroreflection, which is expected.

Thanks again for the review!

[javagl]

There have been some ... changes (hopefully: improvements) ... in terms of the CI quality check. Specifically: The CI now checks for the validity of the license identifiers. In this case, the license must be a valid SPDX identifier, so it has to be
CC-BY-4.0

(i.e. the current value is missing that last -...)

[mklefrancois]

Thanks, I will give it a try,

The SPDX was correct, but the licence was differently written

    "spdx": "CC-BY-4.0",

[javagl]

There may still be some ... "legacy aspects" ... regarding the metadata JSON handling.

But according to the latest state, the "spdx" property in the metadata should no longer be required. Instead, the "license" property should be a valid SPDX identifier (or an identifier for a license that is stored locally in the LICENSES directory).

This was done in order to streamline, simplify, and canonicalize the submission process. Until recently, I think that there wasn't even a mechanism that prevented users from adding some
"icon": "https://example.com/not-safe-for-work.png"
in their metadata. (And there may not be a mechanism that prevents them from doing that today).

But most of the fields in that JSON can be (and now: are) derived from the SPDX identifier. So the only required fields now should be

            "license": "CC-BY-4.0",
            "artist": "hinndia",
            "year": "2024",
            "owner": "hinndia",
            "what": "Everything"

[javagl]

So CI seems to be happy now.

Given that the corresponding PR in the glTF repo is not merged yet, I assume that this should also not yet be merged. But when the time is right, maybe someone (Ed or Alexey) can have a look and review+merge this accordingly.

[mklefrancois]

In the PBR meeting, if I recall correctly, the agreed sequence was: the asset should be merged first, followed by the Khronos Viewer implementing the feature, and then the extension would be merged. I'd be happy to discuss this further on Monday.