GSoC 2024: Draft: Redesigning the Color Ramp and Enum support in all Node Editors

[Noah_Pinales]

GSoC 2024: Draft: Redesigning the Color Ramp and Enum support in all Node Editors

Name:

Noah Pinales

Contact:

Email: [email protected]
Blender Chat Name: @Noah-Pinales
Blender Developer Account: @Noah-Pinales
Blender Forum Account: @Noah_Pinales
GitHub: @noahpin
Personal Website: https://noahp.xyz/

Synopsis

The Color Ramp Node is a versatile node used in many workflows in Blender. However, it comes with several downsides, including the inability to externally edit the color and position values of the various chips via a Socket. In addition to this, I would like to bring the Menu Switch feature present in the Geometry Node editor to Shader and Compositing nodes, for use in node-group based workflows in both editors.

Benefits

This project benefits Blender in several key areas. First and foremost, the Color Ramp node is one that has needed a face lift for a while. By implementing Color and Position sockets, the Color Ramp node will be able to adapt to more Node Group workflows, especially as groups become larger and more complicated, with many different ramps in the group. In addition to this, I see benefit in sharing colors between ramps with different handle positions, which could be a useful feature in some procedural workflows.
As far as Enumeration goes, It has proven itself useful in the Geometry Nodes editor, and would be a welcome addition to the Shader and Compositing editors, especially when used in tandem with complex node groups, so the less shader-inclined users can easily modify node group settings without dealing with complicated inputs or diving into the group itself. This goes for the addition of Color Ramp socket properties, as well.

Deliverables

For deliverables, there are two main deliverables I would like to accomplish. First and foremost would be the Overhaul of the Color Ramp node. As part of this overhaul, I will include Color and Position sockets for each color handle on the ramp, all under a collapsible panel which is open by default. In addition to this, I would like to explore potentially adding new interpolation modes to the Color Ramp, such as Oklab.

The second deliverable would be porting the Enumeration functionality present in Geometry Nodes to the Shader and Compositing editor, adding the Menu Switch node and Menu input type.

Project Details

Color Ramp Overhaul:

The primary goal of this proposal would be to overhaul the Color Ramp node. This would involve adding a new Color and Position socket for each handle, and dynamically updating the sockets when the ramp preview is modified, and vice versa. In addition to this, Color positions would have to automatically sort by position size in the sockets, to align with the ramps preview. As you add/remove handles, similarly to how the Color Ramp currently operates, each appropriate color and position socket would update and add or remove the new socket. Each color and position socket would be underneath a “Color Handles” panel, with the panel open by default to allow for easy access to the color properties, but can be collapsed as the ramp becomes more complex. In addition to this, I would like to add an interaction to the Color Ramp, where double clicking on a Handle automatically opens a Color Input window, where you can modify its color directly. This solves the issue of having one dedicated color input, when the Color Handles panel is collapsed.

In addition to this, I would look into adding Oklab interpolation to the Color Ramp panel. This mode of interpolation would operate on top of the RGB color space. This new mode would require some more research into how exactly interpolation is calculated.

Here is a mockup of the new Color Ramp node.

Menu Switch & Enumeration:

This second goal of the proposal should hopefully not be as challenging to implement, considering the groundwork has already been laid out in issue #113445. I would like to bring the Menu Switch functionality from Geometry Nodes into the Shader and Compositing editors. This would add the new Menu Switch node, and the Menu socket type. In addition to this, the menu switch node would have properties in the side panel which allow for it’s enumerable sockets to be added or removed, and renamed. Functionally, it would operate the exact same way as the node does in the Geometry nodes editor, but it would only support the socket types in the Shader and Compositing editors: (boolean, vector, integer, shader, float, color) for Shader, and (vector, float, color) for Compositing.

Project Schedule

Community Bonding Period:

• Meet mentor & improve proposal and scope with their guidance

• Discuss potential UI/UX experiences with the Design Team

Week 1-4

• Overhaul the Color Ramp node
  • Add Color and Position sockets to the node under a new Panel
  • Double Click interaction on the ramp chips
  • Auto sorting, addition, and removal of each handle socket and position

Week 5

• Research & Implement Oklab interpolation to the Color Ramp node

Week 6

• Test & Bugfix new Color Ramp sockets and Interpolation
  • This is a node that is used across three different editing workflows, and as such it should work flawlessly in all 3.
• Document new Color Ramp node

Week 7-8

• Implement the Menu Switch node in the Shader editor
• Implement the new Menu socket type in the Shader editor
• Implement the sidebar interaction on the Menu Switch node to add enumerable sockets to the node

Week 9

• Implement the Menu Switch node in the Compositing editor

Week 10-11

• Bugfix the new Menu Switch nodes, write documentation for its use in the Shader and Compositing editors, Refine

Week 12

• Padding for delays & further finalization
• Final Evaluation

Bio

I am Noah Pinales, an undergraduate Computer Science student and Product Design Minor at the University of Southern California. In addition to this, I am also a freelance graphic designer and 3d artist.

I have used Blender extensively in my day-to-day for nearly 5 years now, and run a freelance business rendering Mechanical Keyboards using Blender. As such, I have a deep understanding of Blender’s various features, especially the shader graph.

On my own time, I have created several web-applications, from a WebGL based pixel art drawing application, to a very rudimentary vector editing application. I have strong experience in Java, JavaScript, Python, and C#. While I am still learning C++, I have a strong understanding of core programming fundamentals through my experience in other languages, including a good understanding of Object Oriented programming. I am also a quick learner, which has proven useful in navigating Blender’s code.

I believe that I am the best candidate for this project because of how actively I use the features I intend to improve. Many times in my usage of Blender, I have desired to expose the parameters of the Color Ramp node to a Group Node setting, and as such I am incredibly passionate about seeing this feature come to life.

Here are two pull requests I have created recently, both regarding adding interpolation options to various Compositor nodes. From my experience in these pull requests, I have a deeper understanding of the various features a node has, and better knowledge of how they render their UI, which will be integral to my project.

#119902

#119908

They are both WIP, and I intend to do more work in adding interpolation support to more Compositor nodes.

Thanks for taking the time to read this proposal!

[thorn-neverwake]

@Noah_Pinales

Blender already offers a useful feature with node groups, and that is exposing any inputs and outputs you desire with the Group In and Group Out nodes, but one flaw of the Color Ramp node is that the actual colors of the node are not manipulable through input or output connections; they are essentially static. To fix this, I propose the idea of “exposing” these parameters through a context menu, so that they are able to be modified outside of the node group.

I’m going to go to the heart of that matter, as your proposal uses the ramp situation as a base for explanation. The solution I would prefer first, would be for the ramp node itself to be redone, not create new various extra steps and other things involved to be able to manipulate the position and color of a ramp chip.

TLDR: The problem is the node, not lack of extra tools in dealing with the node.

[Noah_Pinales]

That is a very good point. The quickest option I can think of would be to have each color and position pair be exposed via input socket, however this could get busy quickly with more complex ramps.
Another option I can see being somewhat “viable”, yet incredibly limiting would be to have predefined sizes, however that could both create friction and would again be very limiting. In addition to this, having each chips position exposed as a value could raise issues similar to #119648, in that auto-sorting may not work by default, or alternatively sorting as you update the position value could appear confusing to users. This might be a minor issue, however.

I do see benefit in possibly reshaping this proposal towards a revamp of the color ramp node, as I do feel there could be several additions to the node, including new interpolation modes (Oklab, etc). I feel like overall, this may appear as more of a design issue, which is not necessarily very GSoC worthy.

[nickberckley]

For this proposal to be compatible with Blender’s design Ramp should be a socket itself. Right click option will not work.

I always imagined that Ramp and Curve could be Subtypes of Color socket. That what makes most sense to me. And similar idea already exists in Blender. If you have Vector socket you can change subtype to Normal and instead of number input it displays ball that you can rotate.

So, by Blender’s own designs sockets don’t have to be single number fields. I would follow up on that design: Color Ramp node has additional color input socket that you can plug into Group Input. Additionally, you can just create new socket from sidebar and choose subtype “Ramp”.

Additional benefits of this design would be:

• You can expose ANY color socket as ramp from outside the node group. For example, you can plug in Base Color from Principled BSDF into the group input, change the subtype to Ramp and from outside the node group it will expose color ramp. It will work as if you have Color Ramp node dropped between those two. That method can tidy up node trees and require less nodes.

• Even if you’re not using it for node group, if Ramp of the Color Ramp node was color input you would quickly be able to plug in RGB node in it, and quickly override the ramp effect with single color. That would be great debugging tool, because now I have to unplug it, find what it connects to and change its color, then reconnect node again. You would also be able to plug in float to override it with greyscale color.

Similar thing can be done for RGB curves (as subtype of Color), Vector curves (subtype of Vector), and Float curves (subtype of Float).

Main design challenge would be how to display ramp on the node group so that it feels natural and good.

[modmoderVAAAA]

Have you been in contact with anyone of current nodes & physics developers to ensure that this design is acceptable?
I don’t want looks like hate of someelso work. Maybe this still can be accepted by owners of render engines or nodes and physics modules…

Idea of simple exposing properties of internal nodes on the node groups totally violate design of using sockets for such data.
So, we have Menu sockets in geometry nodes, but but in shader this is just python-like hack?

We have design discussion about integrating Fields concept in shader and compositor node trees: #112547 - Material reusability and fields - blender - Blender Projects.
This is pretty large project what is include complete rework already existing shader building pipeline to integrate single value (even non math values, but data blocks (like textures), strings (like attribute names), color ramp / curve settings, and menu) evaluation in material computation.
As more simple task, Color Ramp socket can be added in geometry nodes which is the most modern system in this context and already have Menu socket and Fields concept.

[slowk1d]

I agree with what has been said that this “right-click exposing” solution feels a bit like a hack not in line with the rest of Blender. For checkboxes and menu entries, I would port to shader nodes how things work already in Geometry Nodes. We just got in 4.1 the ability to use menu inputs as sockets in GN, woudn’t be better to look at how it works there and replicate the behavior in shader nodes (same with checkboxes)? Otherwise, we would have two different methods in different editors to achieve the same result.

Regarding Color ramp, I actually think it could be interesting to reshape (if possible) the GSoC proposal and have as main objective to overhaul Color ramp interaction and UI, it’s something that has been asked maaany times through the year by the blender community with nobody tackling it.

[Noah_Pinales]

Thank you all very much for your feedback, In hindsight my “right-click” solution does seem a bit hacky. After some thought, I feel like focusing this proposal more on a complete overhaul of the ColorRamp node, rather than an umbrella feature; this should also help greatly with scoping out the proposal & schedule. I like the idea of a “ramp” color subtype - that itself does bring a few more design implications as I see it, but I will discuss with other developers before submitting my proposal. In addition to this, I may improve/add to some of the features of the color ramp node (new interpolation methods) to make it a more ‘color ramp’ focused proposal.

Thank you again for the feedback, I will update very shortly!

[baoyu]

What about a “Endocytosis” node?

Here’s a mockup:

[Noah_Pinales]

@baoyu

What about a “Endocytosis” node?

Here’s a mockup:

Thats an interesting concept, and is similar to one I had early on in the development for this proposal. However, I do feel like this may result in some confusion in the long run, as the an input socket would then act as a sort of “output”, at least to access the value parameter of the point curve node.

One of the things I am currently struggling to solve, though, is how to separate the float factor from the rest of the ramp. By having the ramp be its own socket, I feel like having the factor be separate from the ramp essentially makes the ramp useless on its own, without an accompanying color ramp node or something else that deals with the factor. Essentially, unless the new ramp subtype was connected to a color ramp node, with its Factor property, the ramp would be useless/adjacent to a single RGB value, as there would be nothing to modify the position to sample the color at. There may be a clear solution I am missing, but that is what I see currently. I may also be making an issue where there is none, as the point of exposing a ramp socket is to solve the issue of modifying the ramp outside of its node, not handle how the ramp is sampled.

A potential solution to this could be making it so that, when a ramp input is connected to a 1-D (as I am calling a singular, “normal” RGB input), it uses 0.50 as the factor value, like the color ramp does by default.

Another issue (or possibly feature) I can see appearing is people inserting non-ramp values into the Color Ramp’s ramp socket. For example, inserting an image texture or a vector map. I imagine this would require iterating upon each dimension, or some other solution. However, that is more for the actual implementation of this proposal.

[baoyu]

You should be awared of that if you insist implementing the UI to be part of the group node, there’s a lot of work to do: Say you implemented the color ramp node, what about image texture node, float curve node, vector curve node, normal node etc…

[Noah_Pinales]

That is true. Because of that, Im going to focus primarily on the color ramp for this, with the intent on potentially building a framework for these other nodes to be built upon in the future.

[And-Woo]

I’d really love to be able to use the color ramp in a procedural workflow. It would be great to exposed the position and color of the stops, there are plenty of proposals on RCS

[Gerstmann_Bradley]

personally I wish we have menu switch and color ramp exposed to group nodes.
but both proposals seem to be against current and or future design of blender. I highly doubt they will be supported by both geometry nodes and shader module.

[modmoderVAAAA]

I tried to make Color Ramp socket in geometry nodes in the past. Mainly stopped by design of socket of data of Color Ramp and nodes to sample them (socket UI is actual Color Ramp, and Color Ramp node is just node to sample socket data for factor), and on the fact that i have not enough time…

Not something to propose for you, just want to share this.

[Rusculleda]

I think the ideal color ramp node would be something like this, where you can add color stops and they add a corresponding color socket and handle position socket, such that when the handle position socket is pluggued, the stop get’s locked in the color ramp to the position fed to the socket. This way, everything can be controlled procedurally.

[thorn-neverwake]

Exactly this, yes.

The inputs for RGB and Space might be overkill for me personally - don’t know that i’d really need that, but i wouldn’t mind it being there. The color / position inputs are spot on.

And while we’re at it, the “click spot” on the ramp position icons is incredibly small in the existing node.

[Timothy_m]

For exposing a gradient to a group node, adding a new socket type could suffice. In this mock up, I imagine that nothing but a group input noodle could connect to this new gradient socket. In the future, however, more nodes could be created to take advantage of the individual color handles/flags and their values.

[Timothy_m]

I think if you’re going to go down this path, by default the node should have those color/position values collapsed.

[brecht]

The design goal for nodes is to turn booleans, enums, ramps, curves and images into socket types, and allow them to be exposed through group nodes using the same mechanism as other sockets. There are some tricky implementation and design questions to solve for this however (versioning, API compatibility, resolving constant values before rendering, …).

For ramps, there are two distinct things which are both needed and can be developed independently:

• Color ramp node exposing individual points as sockets.
• Making color ramps a socket type that can be exposed through a group node.

For enums, the ability to create custom enums would also be good to support, and if so should follow the same design as the Menu Switch node in geometry nodes.

[nickberckley]

@brecht

Making color ramps a socket type that can be exposed through a group node.

Hey brecht, what do you think about making Ramp color socket subtype instead of new socket type? Can that work technically? Because from user-pov I’m seeing that it’s just color data, but instead of single value it has multiple (like a field). And sockets already support that kind of thing.