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.

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

Automatically assign PBR textures from base texture name in BaseMaterial3D #11261

Open
Calinou opened this issue Nov 29, 2024 · 2 comments · May be fixed by godotengine/godot#99838
Open

Automatically assign PBR textures from base texture name in BaseMaterial3D #11261

Calinou opened this issue Nov 29, 2024 · 2 comments · May be fixed by godotengine/godot#99838

Comments

@Calinou
Copy link
Member

Calinou commented Nov 29, 2024

Describe the project you are working on

The Godot editor 🙂

Describe the problem or limitation you are having in your project

Assigning textures for PBR materials in the editor requires a lot of clicks. You need to specify each texture individually, make sure you didn't pick the wrong texture (e.g. from a different texture set or mistaking a PBR map for another one).

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Since, the majority of texture packs out there follow common conventions, this can be automated.

We can both detect the base texture name that was specified, and detect other texture maps related to this base texture name (even if it's not an albedo map). This means that to load most materials out there, you will only need to specify one texture instead of 4-7 textures for most PBR materials.

This also allows correcting for errors, in case you specify e.g. a roughness map as an albedo map.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

  • When a texture is specified in a StandardMaterial3D or ORMMaterial3D in the inspector, check its name.

  • Read the name component by component to infer what texture type it is.

    • Use common conventions from popular texture websites to derive a list of components and their aliases.
    • A component is a substring split by any punctuation in the file name.
    • Try to be as case-insensitive as possible.
    • Pay attention to the order of components, as the material type is almost always listed as a suffix to the texture name (e.g. blue_metal_grate_albedo should be understood as an albedo map, not a metallic map).
  • Replace the detected component with other components in the file name, and check for the presence of this file in the same folder as the base texture.

    • If this file exists, assign it to the material's corresponding texture property. Also enable the corresponding material property if it's disabled by default (e.g. normal mapping).
    • Repeat this process for every texture found, making sure undo/redo affects everything in one step.
    • Display a notice once textures have been assigned automatically, along with which texture types were affected.
    • Assignable properties are based on the current material type (StandardMaterial3D or ORMMaterial3D). If mismatching textures are detected, display a notice to inform the user that their current material choice may be incorrect.

This can work in tandem with #2316. If that proposal is implemented, we could prompt to automatically create an ORM map if occlusion/roughness/metallic maps have been detected, but the material being edited is an ORMMaterial3D.

If this enhancement will not be used often, can it be worked around with a few lines of script?

No.

Is there a reason why this should be core and not an add-on in the asset library?

This is about improving the 3D editor usability.

@mieldepoche
Copy link

I'm not sure I like the idea of a silent action happening when setting a property.
I would rather have it be explicit.

Ideas:

Allow dropping an entire texture set on an empty material slot to set it up automatically Currently, dropping any texture sets the albedo.
godot-mockup-material-setup.webm
  • low discoverability, but really easy to perform, and doesn't add an editor setting.
  • user is explicit about wanting to set and load all of the textures
  • additionally, this could be performed on existing loaded materials (just like currently dropping a texture on a material sets its albedo)
  • this allows for a pretty non-tedious workflow for setting up materials: drop textures in slot to setup material, drop material to file-system to save it as a file if needed, and done.
Add a button to the material inspector for automatic map assignation

It would open a file selector where you'd select the maps you want to be automatically assigned.

Image

  • may get tedious if you have a lot of materials, but can't be easier to discover and doesn't need a new editor setting
Add an inspector option when right-clicking on a selection of textures Would prompt the creation of a new material, located in the same directory by default and named like the common name of the textures by default (`whatever.material`).

Image

When dropping a unguessable texture, fallback to a `Decal`-like behavior

The Decal node prompts a popup when dropping a texture on it, so you can choose which property you want to set. The same could be done with materials in the inspector when the texture type can't be guessed.

godot-mockup-material-setup2.webm

In any case if the material is set up automatically by setting 1 texture, there should be an editor notification to tell the user something happened behind their back.

@Calinou
Copy link
Member Author

Calinou commented Dec 6, 2024

I'm not sure I like the idea of a silent action happening when setting a property.

Just to clarify, there's a toast that appears when the feature kicks in, and it only affects properties set in the editor. Properties set through script act as they did before. godotengine/godot#99838 also adds an editor setting to disable this behavior if you wish.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants