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 · 0 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 · 0 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.

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.

1 participant