Spec gloss material to GLTF/GLB

Questions
1

Hey @Drigax
According to GLTFExporter Docs,

  • glTF Exporter converts SpecularGlossiness materials to MetallicRoughness to match core glTF 2.0 specification.

I’m loosing all settings, colors, clearCoat, etc, happens in both GLTF and GLB.

The imported material is of class PBRMaterial and named __GLTFLoader._default

Edit;
On export, i do get a console warning,

“Unsupported material type: Spec_Gloss_material”

2

You’re right, the PBRSpecularGlossinessMaterial material is not handled by the exporter.

Maybe it’s expected (because the spec has deprecated it in favor of the metallic workflow?) because PBRMetallicRoughnessMaterial is explicitely tested but not PBRSpecularGlossinessMaterial, so I will let @Drigax answer this one.

3

Hey @aWeirdo,

I spent some time looking into this, I think this originally broke when we deprecated the PBRSpecularGlossiness and PBRMetallicRoughness materials in favor of a unified omni PBRMaterial.

Currently we don’t provide conversion from the old material to the new material, and seemed to break the old export pipeline from what I currently gather.

Going to open some issues to track this…I definitely think we should provide some ability to convert from the legacy material model to the new one…

4

Created Create Legacy Material Converters · Issue #9424 · BabylonJS/Babylon.js · GitHub and PBRSpecularGlossiness materials are excluded from export · Issue #9423 · BabylonJS/Babylon.js · GitHub

To track these issues.

@sebavan, I took a quick stab at a converter, but I noticed that there are a number of duplicate fields i.e: emissiveColor, alphaCutoff, etc…

between PBRBaseMaterial and PBRBaseSimpleMaterial or their derived classes.

Do you have any ideas if

  1. such a converter is a good idea
    and
  2. if there is a smart way to handle conversion of these identically named fields? like say casting between them via any
1 Like
5

Cheers for looking at it :slight_smile:
A conversion tool would be amazing!

6

Actually, the 2 specgloss/metalrough are meant to be simpler version following the gltf naming convention as the main mat auto switches workflow depending of what has been filled in.

everything in the end goes through the pbrBaseMaterial and the conversion should be straightforward at this level.

They are not deprecated but more suited to ppl creating materials via code for their simplicity (only one workflow and not all the options).

1 Like
7

Ah, I see, the materials do seem like subsets of the PBR material, just with some varying field names. Good to know.

@aWeirdo the exporter fix is in via

1 Like
8

Hey @Drigax
but only MetallicRoughness is included in GLTF 2.0 specs, so i think specularGlossiness is deprecated in the GLTF format itself?
glTF/README.md at master · KhronosGroup/glTF · GitHub .
@bghgary any insight?

9

KHR_materials_specularGlossiness is a glTF 2.0 extension. It is not and has never been part of glTF 2.0 core spec.

The Khronos 3d formats working group and PBR Next technical subgroup have been considering discouraging the use of the KHR_materials_specularGlossiness in favor of using KHR_materials_specular once the WG submits it for ratification and it gets ratified. Both extensions, by definition, are not part of the core spec.

Both KHR_materials_specularGlossiness and KHR_materials_specular are implemented in the Babylon.js glTF loader. The latter is marked as experimental.

For the exporter, there are a few options:

  1. Export KHR_materials_specularGlossiness extension in the glTF.
  2. Export KHR_materials_specular extension in the glTF.
  3. Convert specular/glossiness to metallic/roughness via a lossy algorithm.

Or we do some/all of them and let the user choose.

@aWeirdo I don’t know what your scenario is, but if it’s possible, the best course of action is to use metallic/roughness workflow at the source. Then you won’t have any issues.

1 Like
10

Thank you for the explaination, that makes more sense now.

Ideally i would like to export the materials, either as extensions(optimal) or converted.
But i can also settle for a exposed/static convertion tool which i could use on import rather than export.

In the end i just need a method to handle these materials so they’re not lost in the process :slight_smile: