Editor Import: Convert to Lit/Standard based materials (instead of custom glTF shaders)

[atteneder]

When importing glTF in the Editor, glTFast currently creates materials the same way than at runtime: with custom, runtime optimized glTF shaders.

However, when using glTF as interchange format, users might want to use regular Lit or Standard shader based materials.

Currently the only way to achieve this is to manually create the materials (which eventually comes with additional chores like swizzle texture channels, etc.)

A setting in the inspector should allow users to pick the shaders that are used. All parameters and textures have to get mapped to this shaders. This setting should default to the current render pipeline's default shader (Lit or Standard).

An alternative would be a material/texture conversion as an independent, manual post-processing step, but I consider this less intuitive.

[ItsCubeTime]

Personally I would love to see support for creating node graph based materials, so that the artist can easily tweak the materials manually after import when needed

[atteneder]

Personally I would love to see support for creating node graph based materials, so that the artist can easily tweak the materials manually after import when needed

Hi @ItsCubeTime,

That's an interesting take. Do you mean tweak material parameters or change the actual calculation (i.e. change the shader graph)? Do you have a specific, exemplary use-case that demonstrates the usefulness of that?

For changing parameters only, we could create an "extract materials"-like feature, similar to what the FBX importer does (as far as I remember). The workaround for now is to duplicate each material and manually re-assign it instead of the original.

For URP/HDRP the custom glTF shaders are already Shader Graph based. You could also duplicate those to replace originals.

Both is kind of tedious and will break if the glTF receives updates from the artist. So it's especially important to understand the intended workflow before.

Thanks

[ItsCubeTime]

Hi @atteneder !

Being able to adjust parameters only would be useful on its own for sure, but I was thinking it would be awesome if one could alter the node graph itself. Usecases are ofc quite unlimited as theres a lot of magic that can happen in a shader graph :)

For URP/HDRP the custom glTF shaders are already Shader Graph based. You could also duplicate those to replace originals.

I had no idea! To me it sounds like what Im suggesting already is whats happening then? Maybe a nice to have here would be if one could somehow disable "updating" of materials on a per-material basis in Unity. Idk if its possible to register stuff to the RMB menu in Unitys file explorer, but maybe if one could just right click the material asset and then toggle "updating" on or off from there (so that the material wont get overwritten if the gltf it derived from gets updated)?

Btw, could you have a look at https://github.com/atteneder/glTFast/discussions/279 . I havent quite managed to get your package working in our project, potential bug?.

[atteneder]

@ItsCubeTime Usecases are indeed unlimited, but my time is not, so I prefer to seek for actual workflows that solve real-world problems first (it's fun to brainstorm workflow ideas though). Maybe a dedicated github discussion is the better place for that to not get dragged away from the original issue/feature here.

[DevSelchow]

This would be a good Feature for me. I have a application where visibility is more important then visual accuracy and i don't control the glb models. I am currently struggling to to have the PbrMetallicRoughness shaders of some glbs be all equally lit in my scenes.(somehow they barely react to directional lights?) Having a simple setting on loading to only use standard shaders would be great.

Edit: I didn't see that this issue was concerning Editor import. I am using Runtime import. Maybe this could apply to both.

[ItsCubeTime]

Something else that I would like to see support for is "standard" HDRP shaders & reusing of existing materials/textures when possible - if the importer doesnt already do that.

Something nice that Unreals Datasmith importer does is that it stores all the materials and textures in a directory specified in the project settings, every time a new import happens it checks if identical materials/textures already exists before importing, if they are already in the project they simply reuse whats already there (on a per texture/material basis).

This would be very useful for my project as we re-use textures and materials a lot between scenes (and as we dont want a bunch of duplicate data!).

[atteneder]

@ItsCubeTime Yes, that's exactly what this issue is about.

At runtime, you'd want to use the glTF shaders, since that way you don't need to change the channel mapping of certain textures, which costs a lot of performance (e.g. extracting the metallic/blue-channel out of the ORM texture).

Currently the Editor import also uses those shaders, since it did not need any work this way.

In the future you'll have the choice to convert to Lit/Standard shaders. I'd argue that this should be the default (for Editor import).

We could also look at runtime import, for people who don't care about texture conversions, but that's not a high priority (as long as nobody convinces me otherwise).

[DelTaGC]

Hi, I think that option would be useful.

The problem I encountered: I receive a .glb file, but when I import it in Unity and build my binaries size is 4x larger because there were many 4K textures in that model.

With a FBX I would let Unity extract the materials/textures and simply reduce the textures size. AFAIK there is no such possibility with glTFast. So a conversion to Lit/Standard with extracted textures could help. Or a feature to limit the resolution of GLB textures at import or build time.

[atteneder]

@DelTaGC :

I can see that a workflow like that would be useful to some/many, but I'm asking myself what would be the best solution. Ideas for approaches:

1. Optimize glTFs in-place/before import (glTF->glTF). This is very specific, but users of real-time import would benefit as well. Also, this could be done by a separate tool or SDK and thus Unity-independent.
2. Extract Materials (like FBX offers). This is very flexibel (users can tweak all kinds of stuff), but relations can break if the original glTF is updated. Further this could be done to all sub-assets, like animation clips, as well.
3. Specialized import settings (e.g. max texture size). Depending on how many there are, this can become cluttered.

A workaround that would work right now already (although a bit tedious) is to duplicate the elements you want to tweak (material+textures), change the texture resolution and re-assign the tweaked textures/materials.

[drjaydenm]

Hi there, personally I am looking for the ability to remap materials at editor import time, similar to how Unity offers out of the box for FBX, OBJ etc. My use case is that I don't want to use any of the gltf material data, apart from the UV coords, and just want to apply a texture via a custom shader graph material. At the moment, I can do this by manually going into every mesh in the model and selecting the custom material, but it would be great to be able to do this at the root level in the import settings, and apply across all meshes automatically. Let me know if I explained that poorly and I can try again 🙂

[atteneder]

@drjaydenm :

I think I got what you mean, thanks. It's a different topic though and (in my opinion) already covered in #305 .

[drjaydenm]

I think I got what you mean, thanks. It's a different topic though and (in my opinion) already covered in #305 .

@atteneder Thanks for that, I've read #305 and you are correct, that seems more closely aligned with what I'm looking for, I'll head over to that issue

[DelTaGC]

A workaround that would work right now already (although a bit tedious) is to duplicate the elements you want to tweak (material+textures), change the texture resolution and re-assign the tweaked textures/materials.

That is what I would usually do, but these textures are .texture2D with no settings to change resolution. In the Inspector they only expose WrapMode / Filter Mode / Aniso Level. Also when duplicating the texture, the editor prints an error: "Instantiating a non-readable 'MyTexture' texture is not allowed! Please mark the texture readable in the inspector or don't instantiate it."

[atteneder]

A workaround that would work right now already (although a bit tedious) is to duplicate the elements you want to tweak (material+textures), change the texture resolution and re-assign the tweaked textures/materials.

That is what I would usually do, but these textures are .texture2D with no settings to change resolution. In the Inspector they only expose WrapMode / Filter Mode / Aniso Level. Also when duplicating the texture, the editor prints an error: "Instantiating a non-readable 'MyTexture' texture is not allowed! Please mark the texture readable in the inspector or don't instantiate it."

Right, good point.

[aiaustin]

When using the Unity glTF importer, the first thing I looked for was some mean to externalise/extract the materials so I could tweak them in the unity project. I have found that very useful when using the FBX importer on similar meshes. The particular issue I was looking to fix was elements of the Blender glb exported model that in Unity looked shiny black versus the aluminium shiny finish expected and as seen in Blender.

Was any progress made in perhaps adding an extract materials capability for external manipulation to the glTF importer?

[atteneder]

Was any progress made in perhaps adding an extract materials capability for external manipulation to the glTF importer?

That's not a priority at the moment, so no, unfortunately. Subscribe to #305 to get updates.