Material Asset Workflow

Currently in master it is possible to use materials as assets. It has a very limited workflow as only a minimal workflow is working.

Current situation

Materials can be marked as assets. When marked as assets it is possible to drag and drop the material from the asset browser (or asset template) to an object in the 3d viewport.

The material is 'applied' to the object that would create a new instance of the material and its linked images and node groups.

When a material is applied it is always applied to the first material slot.

When a material is applied to multiple objects the material (and its dependencies) are duplicated in the scene.

The icon in the asset browser uses the same icon preview as the material. This can be changed in the material properies in the Preview panel. When changing the preview icon for an material that is marked as asset the asset browser will still show the previous icon. In the asset browser the icon can be refreshed by opening up the side panel and execute the refresh icon operator.

Apply-ing material

Apply-ing materials as described in the current situation can be resource hungry (See resource handling) and might not be the way that users expect.

Alternatives

1. Link material and images
   • materials aren't local and cannot be changed directly.
2. Materials are appended, images are linked
   • Changing materials would change only this occurance of the material.
3. Materials are appended and de-duplicated, images are linked
   • Changing materials would change all occurances of the material.
   • Unclear how materials can be de-duplicated

Material slot

Currently only the first material slot is effected. Users cannot assign a material to another material slot.

Alternatives

1. Update the selected material slot.
   • Can we clarify this to the user. render text that 'Material is applied to slot #' Could also be text near the mouse-cursor/draggable content.
   • Workflow isn't really drag and drop as users first need to select the slot in the material tab.
2. Use sampling to detect the slot where the material is dragged upon and update that slot.
   • Perhaps only support this in viewport material/render mode or solid material/texture mode.

Icon handling

By default the preview panel in the material tab is collapsed as updating the icon on every change is resource hungry and can make the UI less responsive.

As the options are hidden the material preview is might first be seen by the user in the asset browser. If a user wants to change the preview icon the workflow is cumberslome:

1. go to material tab
2. expand material preview panel
3. change preview icon
4. go to asset browser
5. select material
6. open side panel
7. execute refresh icons

Icons can be out of sync with the material. This is for any asset type.

Alternatives

1. Keep current implementation
   • Is consistent with how other asset-types work.
2. When switching the preview icon the asset icon should be automatically updated.
   • Keeps workflow consistent with other areas, only autoupdates the asset icon
   • Overhead as icon is also updated when tweaking the material.
3. In the preview of the asset material show the icon selector, that automates the process, but duplicates some logic mostly in python. The material preview icon and the asset icon will be kept in sync.
   • adds duplicate code from material to asset browser. code should not be there.
4. Split the preview icon rendering so assets can have their own icon selector.
   • adds complexity in the render_preview

The choice is actually how consistent we want to keep the workflow with other asset types.

Reflective and transmissive icons

When rendering icons there is no surface to reflect from. This makes reflective and transmissive materials hard to read. This effects both Eevee and Cycles materials.

Alternatives

1. D11988: proposes to add a surface that isn't visible to the camera, but would be interact with when used with reflective/transmissive materials.
2. Make the icon render the same as preview render.

Icon size

Currently icons are rendered using a resolution of 256x256. In the asset browser you can zoom in and see individual texels.

Alternatives

1. Use a higher resolution
   • Increases render times
   • Increases memory and file size
2. Use upscaling techniques (FSR or alike)
   • FSR doesn't support OpenGL, but seems like it could.
   • Needs more research to identify actual impact.

Resource handling

In the current solution Materials and Images are duplicated. This has technical consequences, elaborated below.

• As materials are duplicated EEVEE will generate GLSL for each material. If the GLSL are identical the GPU driver most of the time would identify and load a pre compiled program. If the actual program bytecode are shared is a driver responsibility.
• Blender caches GPU textures for images on Image level. This means that for every image that is used in the scene there will be a GPU texture resource and data would most likely be duplicated in the GPU driver as the data is owned by the GPU driver.
• Blender Image cache does checks based on file location so Image buffers should be deduplicated. (ref: IMB_moviecache)
• Cycles (SVM) doesn't seem to do any shader graph de-duplication. Byte-code would also be duplicated on the device. Byte-code doesn't utilize much space (order of kilobytes per shadergraph).
• Cycles has an image manager that de-duplicates images based on image paths and usage (interpolation, alpha mode, etc). (ref: ccl::ImageManager::add_image_slot)

Of course these technicalities could be changed if we have a case.

Alternatives

This needs to be decided after actual workflow is selected.

Open issues

• The workflow should be discussed in a larger group as objects/collections might want a different workflow and this would lead to less consistency between the object types. Not saying that that is bad thing, but it should be discussed and approved.