Add support for "Channels" to the Color Attributes #108404
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
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
EEVEE & Viewport
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
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
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
EEVEE & Viewport
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
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
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
7 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#108404
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
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?
This design task is part of a request from a major game development studio who is actively using Blender in production.
Currently, for Color Attributes, we can specify the domain (Vertex, Face Corner) and Data Type (float32RGBA, int8RGBA)
This is a proposal to add a "Channels" panel to the User Interface, similar to the "Channels" tab found in many popular 2D drawing packages.
(Attached is a screenshot from https://www.photopea.com . We would not include the "RGB" entry or the layer preview)
The proposed "Channels" panel would most likely be a sub-panel of the existing "Color Attributes" panel, although this part may be subject to change following user feedback.
The "Channels" panel would have four entries corresponding to:
This first part corresponds to the "User Interface" portion of the task. (Including serialization of the UI state.)
Each of the entries would have a toggle to show or hide the channel. The current behavior is associated with all channels visible.
If only one channel is visible, the associated channel would render as gray-scale if the viewport is in "Vertex Paint" mode, and potentially in other visualizations also.
If the Red, Green, or Blue channels are hidden, the visualization will render as if they were zero.
If the Alpha channel is hidden, the visualization will render as if the Alpha was at full. (Either 1.0f or 255)
If no channels are visible, the visualization will render black.
This second part represents the "Visualization" portion of this task.
In addition, each channel entry will have a selection toggle. Again, the fully selected state corresponds to the current behavior.
The selection state will affect the operation of the "Paint" style tools, and potentially any other operators which affect the color attributes, including Invert, Levels, Brightness/Contrast, etc etc.
This third part represents the "Modification" portion of the task, and bounds the complete scope of the task into a manageable amount of effort while still providing considerable value to the Game Dev Studio's workflow.
It is important to note that at this stage, neither the Channel Visibility, nor the Selection State will modify the Data Transfer nodes, baking, scripting, Color Attribute creation, or any other indirect way of modifying the Color Attributes. These may be added on later in a separate Design Issue, but this issue is restricted to direct manipulation of the Color Attributes by the user.
Note also, this particular Design Issue does not change the export of any data from Blender, only the display and user interactions.
I imagine there should be a lock toggle too.
I think the "Lock" toggle goes on the Layer tab? But I'm certainly open to adding it here as well, just not quite sure how it would work...
For some inspiration, it's worth note that compositor has a channel display UI.
It's pretty convenient as a display option (quick toggle with dragging for example) but I guess it gives little room for more advanced operations per channel.
I'm not sure if you want to change how attributes work. And why the geometry nodes and the python interface as a way to add this weren't considered. But how will this interact with geometry nodes and all other attribute types?
Oh that's cool! I didn't know the compositor did that, will check it out.
I'm not really following? I don't think this change will affect geometry nodes or the python interface or any other attribute type?
AFAICS, this change is only about Color Attributes and their interactive editing within Vertex Paint.
Are there other interactions here I should be aware of?
This kind of metadata in geometry nodes:
Why does it have to be exactly in the attribute data (seems to be for texture drawing / editor, is it a global editor flag, not texture metadata?).
If you just want to add a custom attribute preview effects (without any other real logic), then why not:
It may not seem as reliable, but I wouldn't have the questions above.
Yes this is not just found in the compositor but also the image editor:
So far this is only for the "display" of channels but doesn't affect "editing".
It seems logical to make this setting affect both. In that case it could be moved to the center of the header next to the image selector to make it more clear that the setting affects all brushes and operations.
A similar thing could be done for the 3D viewport. It was planned anyway to move image/attribute slots in the center of the header as well.
I think there is still a use-case to separate out the visibility of the channels from the editing of the channels.
One possible path forward might involve implementing this first in the image Editor, the unifying the functionality in the compositor, and finally bringing all the unified changes across to Vertex Paint and Color Attributes.
...In any case, it looks like I've got some homework to do...
In terms of the original proposal:
No change.
Nothing to clear, there is no user action required to clear it.
No change, nothing here to do.
Yes, both color types will be supported.
(If other color types are added, e.g. RGBAA, RGBAAA, R10G11B10A1, they will need to be supported too.)
It's only the Color Attribute on Vertices. This is not a global editor flag.
Why? The request is coming from a major contributor to the Blender Foundation to streamline their current workflow in production on a game that is currently enjoyed by millions of players.
It's not just a preview, the third part of this proposal affects the interactive vertex painting.
This is just the first of a series of change requested by the game developer. There are follow-up requests as well which are dependant on this change working in this way.
...Some of these answers may change based on my homework from up above...
Well, gamedev studios will likely have a lot of requests, some studious we work with use custom builds to satisfy their demands.
But should they be solved as a lots of independent and separate tasks at the core level?
Sorry, but these are not questions of what you will do.
These are questions of how users can break it and you need to handle it.
We already have a some issues of similar meta data about the active color attribute and the render color attribute. Just some of i can fine now:
Yeah, totally. In many ways, that's exactly what this Design Issue is about, how do we incorporate these requests in a way that makes sense in an open-source project?
If it helps to put this in context, there are other things they're asking for which have already being triaged in different ways.
My apologies, I misunderstood.
I'll take a look through these and see if I can get a better understanding of the interactions between Color Attributes and Geometry Nodes at the user level.
The problem is that Gamedev is known as heavily technically deep specialization (mostly because the result is supposed to be run in realtime which puts sufficient limitations), the compatibility of a software with gamedev assumes satisfying quite certain conditions.
For example, UV packing with exact margins that was implemented is welcome from the point of view of different specializations, but in gamedev it is straightly critical because of baking and mipmaps.
Solving those issues separately in some way may be like designing a diesel engine by designing its parts separately from the whole concept.
Hello, conversation newcomer and professional game dev here!
I was speaking with @Chris_Blackbourn in behalf of my art team, and those conversations are what got this conversation rolling initially, after agreeing with my studio team that this is something we, and others we've worked with over time, see as something that Blender would greatly benefit from having refined.
Also to be clear, the intent was not to just communicate it as a feature request, but more along the lines of "if the game development pipeline is important to the Blender team, they should know how we use Blender and where we see the kinks in trying to use Blender within the pipeline." We put out a survey among Blender users within the company asking where users thought Blender created problems, and this made it to number 1. So regardless of whether anything is done about it or not, at the very least, the game industry (at least if we were to represent the game industry to some extent) and the Blender team are on the same page about where Blender falls short in the pipeline. A good "FYI".
In response to some comments made here:
Blender's main focus and core audience does seem to be on the film production areas. However, I'd go as far to say the second biggest user base would be game developers - do you think that's accurate?
Vertex colors for use in shading is a very broadly used technique in the game dev industry, and is not just studio specific, similar to the UV island margin you mentioned. The way vertex color tools work currently (specifically as sort of shader "masks" or similar weight painting, as opposed to color painting for a render as you would on a sculpt) are manageable but difficult and complicated to use. It has a very hacky feel to it all, and with it being such a broadly used technique, I can't help but feel it deserves a refreshed Blender's UX polish to it. Core functionality is there, but it feels very unsupported, overlooked, unimportant to the Blender devs eyes (which is understandable) or maybe a little misunderstood (at least to the needs of game development if seen as an important enough feature).
From what I understand from the comments made, it seems to be a question of "is this just a single studio request for some obscure tool" or something. Is that correct? Looks as though this wasn't seen as important enough to look into further, which I can accept and understand if that's the case.
It is the opposite.
I think it is important to track, indicate and collect gamedev related tasks separately because any studio which perform gamedev-related workflows will face the same technical limitations and demands, which are solvable but are quite technically deep, and usually require additional understanding and exploration of a gamedev specific workflows to be solved correctly and functionally complete.
Blender has a huge potential in gamedev related areas, like assets making for example, but unlocking this potential requires a deeper understanding of the specific requirements.
Hope it sounds more clear, I have a language barrier.
Thanks for the response, Paul. And thank you for clarifying, that makes sense.
If it ever becomes a more core interest for you, I and others would be more than glad to continue the conversation to strengthen understanding on how game developers are using Blender for their needs. Vertex colors seems to be a main universal struggle so far, but for many it's the go-to modelling tool it seems.
Thank you!