User defined default color for images #107016
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
6 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#107016
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The Default Color
If you map a texture in such a way that the image doesn't cover the entire model, the default color should show up.
Interestingly Blender does have a default color and as far as I know the only way to see it is to set an image texture extension mode to Clip. In that case, any UVs mapped outside of the image space get the color black (0.0, 0.0, 0.0). However this default color can not be currently defined by the user.
The Panic Color
The panic color for images AKA the bright magenta (1.0, 0.0, 1.0) appears when an image file has not been loaded correctly. It's meant as a visible warning for missing images.
The Problem With UDIMs
External texturing tools are able to skip UDIM tiles that do not contain any valuable information apart from the base color value.
Blender doesn't correctly support variable size UDIM sets and expects all UDIM sets to be of equal size.
The panic color currently shows up when dealing with variable size UDIM sets (color, normal, roughness, etc).
As a way of an extremely simplified example I've created the following file featuring a material with 2 UDIM sets, one for the Color and one for the Normal.
The problem appears because the 2 UDIMs are not conformed by the same number of tiles (images).
The Color UDIM with 3 tiles:
The Normal UDIM with 2 tiles:
The Normal UDIM delivers the panic color (magenta) in the non existing 1003 UDIM tile.
This is incorrect behavior since no image is really missing (there can not be a missing image if the tile does not exist in the first place).
The proposal
Allow for the default color to be user definable.
In the case of single image textures with extend mode set to clip, this color is applied to any UVs that exist outside of the (0.0, 0.0) - (1.0, 1.0) space.
Default color set to (0.28, 0.25, 0.2):
In the case of UDIMs this color is applied to any UVs that exist outside any tile.
Default color set to (0.5, 0.5, 1.0) AKA the bluish normal base color:
For existing tiles that have failed to load their image (missing images). The pink panic color is still expected.
Panic color to be expected since the tile exists but it's image was not found.
User defined default color for imagesto WIP: User defined default color for imagesThink is a good startingpoint.
Just for clarity I think that the 'default color' is stored inside the Image data-block not in the node itself. The node will read it from the Image data-block. Not sure if it is important to show this property at all inside the shading node as it might confuse some users.
Perhaps we should only use this color for missing udim textures. What should the default color be? Pink, Black, ...
We already have a default color for generated images. So we need to check if we want to use the same property or use a different. I think it is better to have a new property to store this color as it will have a different description.
what do you think?
Can't think of any default color that makes sense for all cases. I'd say pink is a good default color since it is easy to spot that there are "missing" tiles. Also it's what happens right now anyway so it would introduce no change to existing scenes.
Other than that, Node Wrangler could be updated to auto-load PBR textures with better default colors based on the texture type (roughness, normal, etc).
I think saturated magenta has been chosen for error detection because it is nice alerting color which is quite rare in the real word.
For example, if you render with missing textures, it is easy to detect the resulting cyberpunk vibes because of a missing textures.
Can you please clarify - why it should deliver bluish color, while it does it direct job - showing that something is missing for a proper error handling (a missing udim in this case)?
The key to understand the problem is those UDIM tiles are missing on purpose. Certain production texturing tools can export variable size UDIM sets. Blender doesn't allow this and expects all UDIM sets to be of equal size, creating magenta errors :)
Updated the proposal to cover some concerns by @1D_Inc as well as my own findings.
WIP: User defined default color for imagesto WIP: User defined background color for imagesWIP: User defined background color for imagesto WIP: User defined base color for imagesI find the UDIM example rather strange. A few questions / comments:
Unfortunately real world production models do come like this. And in some cases it's not about 2 or 3 tiles but hundreds of tiles per set with random ones missing on each set (deemed unneeded). So this is more about being able to load and render files exported from other software correctly.
What you mentioned about generated textures is interesting and yet another way of looking at this.
But again, if there's geometry in those "missing" tiles, you providing a default value is still going to result in a "wrong" render won't it? How are these models expected to be used? Do they expect the users to guess that they need to use Black instead of White for their missing "mask" textures? And they expect people to use a default normal color for the missing normal maps?
I've renamed the proposal to user defined base color. Based on your comments I think the word default is confusing.
And yes, that's exactly how it works! The mask is probably the greatest example of all. Imagine a model with 300 UDIM tiles and now you want to add a logo decal somewhere. Probably only one or 2 of the UDIM tiles is going to be used for the white mask. The rest will be "missing" and rely on the user defined default color of black.
Technically, UDIM tiles has fill tile option, but such empty tiles are lost after syncronization with texture folder.
Why this is WIP, this isn't pull request i guess?
WIP: User defined base color for imagesto WIP: User defined default color for imagesI've rolled back the naming to Default Color since I've confirmed this is what artists with industry experience expect.
WIP: User defined default color for imagesto User defined default color for imagesEdited the proposal to show the use case of Default Color for single images.
There is a benefit that this proposal adds that unused tiles don't occupy space. the fill tile option would create a new tile and adds some overhead, even when the tile is 1x1 Eevee would still need to go over this tile to match the UV coordinates. When the tile doesn't exist it adds less overhead. IIRC Cycles does something similar.
Note that the more complex a model gets the more likely it will become to have missing UDIM tiles. For example when using multi material models where a feature is only needed for a specific material/part of the model. These models could be optimized to use less memory.
Looking at example base human meshes that are being used by VFX movies. They already use 50-100 UDIM tiles. Now when the model has some cybernetic body parts, that for some reasons is added to the base mesh, which uses a metallic UDIM texture, you only want to specify the tiles that only covers those parts.
Yes, the point behind the idea if a having missing tiles support is clear, the examples are good.
Just want to mention that having the ability to quickly detect missing tiles from model's visual appearance is important for model's debugging, for example, before export for using in other applications or UV packing/repacking process.
Something like a checkbox that globally but temporarily enables magenta for missing tiles so you can quickly analyse the model (for example, to distinguish which part of it is solved by texture and which part by image background color - to make sure you provided all the necessary textures) could work well.
The images are not missing. Also you can change the default color to magenta if you want to check for that.
You only know they're missing because you have a native format (like the .blend file) which actively remembers how many tiles there should be.
When you receive assets by other means -- either as a random .zip or USD archive or as a MaterialX material -- those formats don't tell you how many tiles should be there. All you are given is that virtual path.
e.g. A USD asset will only have
color.<UDIM>.png
. There's nothing in the format or specification about how many files that path represents and should be found on disk.The pink color is meant for textures that have gone missing. Blender can not possible know if a texture was missing from the start. Same for regular (non UDIM) textures. What pink needs to help detect is when a model that is already loaded has broken an existing path. If a texture has loaded once, it will be detected when missing.This is already covered in the proposal.
To help detect an irregular number of UDIMs we need a tile counter visible. I will add that to the proposal or create a PR myself.
That would be awesome. Thanks)
@Sergey Pointed out that this could be implemented by the Render & Cycles, Eevee & Viewport or even Core modules. This is not really a Sculpt, Paint & Texture task.
I'll tag them here for this issue.