Mix Node #92588
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
14 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#92588
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?
Mix Node
This task outlines a design proposal for a
Mixfunction node.Similar to
Mix RGB, theMixnode performs a linear interpolation between two values. The current way to perform this for floating-point values is to either useMix RGB(which implicitly converts the values to colors) or to create a custom node setup or node group comprised of low-level math nodes. Either approach is not straightforward to users.This node will likely live under the Utilities category.
Use cases
This functionality is used often to blend between two values.
Potential Issues
Maybe lack of immediate foresight to see other mix possibilities in other "Everything Nodes" projects?
Additional Questions
Changed status from 'Needs Triage' to: 'Needs Developer To Reproduce'
Added subscriber: @Jarrett-Johnson
Added subscriber: @HooglyBoogly
I would include at least a few other type options, since the operation is the same, like the vector map range, D12760
Added subscriber: @GeorgiaPacific
Added subscriber: @CharlieJolly
The Map Range node does linear interpolation too but in a less obvious way. I'm a fan of making things easier for users.
I'm thinking about the name a bit. "Linear Interpolation" would be the most correct name, but I wonder if people expect to have a node called "Mix", for whatever reason.
Another possible name would be "Interpolate". It could be that's a bit too general though, or too specific, meaning it precludes the mixing of other types.
Added subscriber: @Aeraglyx
Added subscriber: @SimonThommes
I think it would be great to have this node implemented in a way that allows to mix any possible datatype similar to the switch node.
I don't see an issue with the name
Mix, I think that is what people would expect. Interpolation types can be solved separately in my opinion.The UI of the node should match the one for the
MixRGBnode: Factor on top and the mix input A being the primary input for automatic connection.Added subscriber: @SteffenD
Added subscriber: @Florian-10
Please a clipping checkbox like Mix RGB.
Thank you!
Added subscriber: @gtitaev
I propose using multi Input Socket and adding customizable factor intervals like in ColorRamp Node:
Or do it with another node: Multi Mix
Added subscriber: @Rawalanche
This should be a different node. The basic Lerp/Mix node should really just be A input, B input, factor input and one output. It would not make sense for users to come in contact with such a complex UI every time they want to just lerp two values.
Here is a possible solution for a mix node. D13731: Function Node: Mix node
I've kept it straight forward with option to turn off factor clamping.
I've not added Blend modes or alternative interpolations.
These can be created by plugging in other nodes to control the factor.
Added subscriber: @Bradley_G
When I designed my node group of mix Node, I kept clamp above the factor.
Updated patch and moved bool socket:
Just curious, what would be the practical use case of wanting to clamp the resulting computation on some parts of the field while leaving it unclamped on the others? It feels like unnecessary amount of flexibility.
Exposing the clamp socket also allows this input to be exposed in the Group Input for example. It's probably unlikely users would want to clamp some parts of a field and not others but I vote on the side of flexibility! 😄
Ah, the group input. Yes, that actually makes sense :) But in that case, shouldn't it be a constant instead of a field? (round socket, not diamond one). The only reason I am asking is that if it's a field, I'd expect there to be some overhead as the bool needs to be evaluated per field element. The overhead will probably be relatively minor, but at the same time, Mix node will probably be used quite abundantly.
I honestly don't think that clamping should be the default for a generic mix node.
I'm actually not even sure it should be an option in the node at all.
For
MixRGBspecifically it makes sense for the workflow, to avoid colors outside of 0/1. For generic mix operations of value/vector maps though I don't really see that much inherent value in this input.I'm fine with keeping the
Clampcheckbox as an option for legacy reasons, but I don't think it should be a socket. To me it is rather a node option than a node input.In such a case "Time" won't stop counting, so a clamp is really needed, whether I do that using an extra node or directly inside the node.
I think it's kind of convenient that dev directly provide a checkbox to determine clamp status directly, instead of me constructing a switch in case anything happens.
Here I stated the necessity for me to have this clamp, and the advantage of having it as a socket.
On the other hand, I don't see much cost having it or making it into an option, unless otherwise indicated.
I also think it's more of a trend in the future that more options will be exposed to users (such as enum list proposal, etc.)
Whether we make the clamp as a default value is questionable though. I may not clamp it by default. Just like we don't clamp math node by default.
I'm not opinionated on whether
Clampis on by default, it's easily changed. Having the option makes sense for aFactorinput and is why theMix RGBfactor is clamped. In contrast the node could default to clamp off.This function could also easily be added as a
Lerpfunction in the Math nodes.I am actually seeing a few good uses for the clamp option. Extrapolation can be useful sometimes. And the socket makes sense for exposing that option to a parent group, as Charlie has said. I just don't think it should be a field, but it's still a good option to have.
I might be misunderstanding something here.
The
Clampcheckbox in theMixRGBnode as it is right now does not control clamping the mix factor, but the the mix result of the node. It clamps the output, not the input just the same as theClampoption on the math node.The factor input of the
MixRGBnode has a hard min and max and is always clamped, regardless of the clamp checkbox. Extrapolation is not possible with that one. I would be strongly against changing what aClampoption on two different mix nodes does. That is just confusing. If a different behaviour is intended, it should also get a different name.That makes sense, but if your point is that currently, Mixing in Blender is a different concept than Linear interpolation, then all these new nodes should be named Lerp. Otherwise, if terminology consistency is a priority here, it would mean all these useful nodes would have to work in the same wonky way that the old MixRGB node does.
@CharlieJolly, to avoid misunderstanding, what about naming "Clamp" to "Clamp Factor" to distinguish it from the clamp in other nodes.
My point is not that a generic mix operation should follow the MixRGB node exactly. I think it should allow extrapolation. Toggling this functionality should just not have the exact same title as a different functionality on multiple other nodes.
So maybe you are right and the node should actually be called something different, like Lerp. But regardless of the name of the node, I think the toggle should not simply be called
Clampbut instead something more specific, likeClamp Factoror (negated)Extrapolate. Maybe there are some better ideas.Extrapolate would be a UX disaster. Average user is familiar with the "Clamp" term, but Extrapolate is rather obscure term among artists. Non the less, for the most users, if they see a "Clamp" toggle on such node, the will expect it clamps the output. The worst thing we can do in Blender (albeit it would be a very Blender way of doing it), is to either use some more confusing term than Clamp, or make Clamp do something else, and then every time there's a bug report or forum post about it not working as expected, some jaded user or developer would have to start explaining the internal reasons. Users do not care about those, they care about expected result. And the expectation is that there is a Clamp option, called Clamp, which Clamps the output.
Here is another patch without clamping and also implemented as a shader node too.
Shader nodes currently do not support Bool sockets, so I removed clamp.
D13749: Node: Mix node
I've also added Lerp and Inverse Lerp to D13550: Nodes: Expand Math and Vector Math functions. For vectors this is per component so this is also another option.
This issue was referenced by
bfa0ee13d5Added subscriber: @MCAN
Workflow issues: I think its good to keep the old MixRGB node in the Color menu that can have a name (Legacy) or just Mix Color or MixRGB because its a very common workflow to justt go color menu and use mixrgb for just simple color mix than mixing vectors and other things, making it away from color menu is such a big workflow change and things are harder to keep changing the default float to color and having all those extra long node just to mix RGB, why not nodes cannot seperate Color from this generalized node that can include more complex things. Color mixing is a frequently used thing that is not inuitive to treat it like general converter. At least there can be option to use old MixRGB along with General Mix node instead of hiding from node list. Or At least, old projects can stay unconverted and use old mix node so it wont be hassle to have taller node that can cause issues. All other softwares keep legacy nodes or effects instead of converting them so people can use them if they want the old workflow.
We have seperate xyz node and seperate rgb node, seperately and many more examples of seperate nodes such as vector math and regular math for float , so why we make a generalized node for Mix that we need to change color float and vector that we access from same place and keep keeping eye on which mode is it?, they can be seperate nodes or at least color can be a different node, or if color still wanted to be included, there can be a seperate color node on color menu just for color by not removing old MixRGB/ Mix Color and adding Vector Mix node and regular Mix node for float and MixRGB node for color , its not good to generalize everything. Its easier to access to what you want to do when they are seperated. Thats why menu exist and categories exist on node selection menus. Uber generalized nodes can also be added but its bad to remove old seperate versions and making people use uber nodes for simple things,
Its easier to make it consistent by seperating mix node for vector and color and value to make things consistent and also providing an extra uber generalized mix node as option
Also removing RGB word from nodes and exchanging with Color is inconsistent while removing Color1 and Color2 from inputs and replacing with A and B for all 3 modes. Float term is also better to be called as Value, blender always call it value in input node, Map Range node also should have value output instead of result. Instead of clamp factor and clamp result, it can be simply clamp output if thats why result is being used. i think its too much mixed up now. Result word is not common, it should be color or value or vector according to chosen mode. I think more inconsistencies happen while trying to generalize and fix things...
Or at least clamp checkboxes and type changing dropdown menus on nodes should be exposablefor node groups so someone who doesnt want all that extra options and want to use the old MixRGB, can make his own node groups for Mixvector mixrgb Mixvalue and use it as their own workflow.
@MCAN I've addressed the menu in this patch D15887
Exposing enums as sockets is not currently possible. This also applies to Boolean items in shading nodes.
Socket naming in general is still inconsistent but A, B and Result are used in many new geometry nodes.
@CharlieJolly Jolly (charlie)
Thank you so muchhhhhh for considering my detailed feedback and adding it to Color menu as Mix Color, now its more consistent and usable like before. I am glad to see that in new build. I really appreciateeeeeeeee!!!!!!!!!
Regarding input name inconsistency for mix node,
Its really contradiction to seperate/detailize/ mixrgb to float, vector, color to make it more specific while removing ''specificality'' of the input and outputs naming.
Yes,its used in geometry nodes sometimes but shader editor came first before geometry node happen and shader editor shaped blenders terminology first, but geometry node namings are adopted in new nodes (which are less user friendly and technical) while ideally geometry nodes should have adopt shader editor to be consistent overall., Fixing RGB to Color made it more user friendly and consistent because Color was commonly used in inputs and outputs. but inputs names are still a problem for Mix node to use A and B. A and B is not always used in geometry nodes, and there are many naming mistakes in geometry nodes because so many nodes are created by many people in short time. by just focusing on adding feature, So it didnt make a new standard, they broke the standard and well principles of it and this mix node also help breaking that standard
Lets take a look why using Color, Vector, Value input is more accurate for Mix node by showing perfect example of input change by enum such as Map Range node, and all other nodes that adopt the naming input as Value and output as value.
3-0. Math node has many functions but it still use value word for regular math node's inputs and Vector word for vector math's inputs.
Only compare node use A and B because comparison is a fuction and usually A and B is commonly used in math during comparisons, so math minded people who add those nodes just focus on feature and call it A and B. But its still shouldnt be preffered because math node also has ''greater than'' comparison option but it still use Value input or vector math node use 2 vector inputs
3-1. Most of the geometry utility nodes use'' inputs as VALUE and output as VALUE'' instead of using result and A and B
Only most common one that use A and B is COMPARE node, but all other ones use value input for most of the nodes
3-2. Map range node in geometry nodes has enum vector and float and when u change enum to vector input says vector and when u change enum to float input says value, so MAP RANGE node shows that its possible to fix that naming issues by coding its not a limitation to change input names for each enum
3-3 Most of the geometry nodes has issue with naming when u change enum from float to vector, it still shows the same input even, so its not a standard or delibarete thing made for inputs tostay same . its probably because many geometry nodes are created in short time by focusing on features while forgetting naming, so making this mistake keep gooing will make blender more messy
So Result is only used as output name for CLAMP, MAP RANGE , COMPARE NODE and A and B is only used at COMPARE NODE, but all other geometry utility nodes use ''how it should be ''naming principle of shader editor and Blender by using ''VALUE output'' such as FLOAT CURVE NODE, RANDOM VALUE NODE, INTERPOLATE DOMAIN NODE, FIELD AT INDEX NODE and also Value input for ALMOST ALL GEOMETRY UTILITY NODES except Compare node
And there is a how it should be example of Map RANGE node that change input and output names to VECTOR OR VALUE output whenu , depending on which enum u choose, so its technically possiblee
(Not the mention Float is used in enum menus but value is usually used in inputs except float to integer node because its main purpose is to differentiate integer and float, so putting float as input naming is also not right if the enum menu doesnt differentiate between integer and float. So value is better to be used with mix node if integer mix option wont be added.)
(Also, blender already use clamp in many things and in tooltip it says that it clamps result, but many nodes use color or vector as outputs, and everyone is aware that result means output rather than a special value type for certain nodes, so it is a general term to say output, so clamp option doesnt necessitate calling output of mix node as ''result'' just to be able to put clamp result naming, it can still stay even output names change with enums''
Therefore, taking wrong examples for new nodes only will make blender more inconsistent rather than taking good examples and majority as a reference , fixing majority is harder than fixing minority to make everything consistent. So I hope it will be fixed soon...
@MCAN I agree that it is inconsistent. There is a patch to rename Fac to Factor here D13359. If you read the comments, changing the sockets is not so easy. Blender probably needs a style guide for naming sockets.
Added subscriber: @Secrop
I haven't been looking into these Design topics for a long time.. so this is probably too late for a change, but here my two cents:
A node doesn't take too much space in memory, and defining the execution tree based on the node's type or the node's properties doesn't seems to make much difference either!
I'd prefer to have more nodes, each calling a specific function, than having one node with a lot of options.
It's a bad UI design, and in Blender it makes it difficult for distinguish apriori what's the purpose of that node (not to mention the weird consequences in the Node Editor when changing the node's UI).
The main problem with having more nodes is how we present them to the user, specially the AddNode menu.. but that could be solved by using subcategories (menus inside menus).