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

I made a post about this a long time ago, the idea is to create a new type of variable (gradient)


I have a need for it. Others have a need for it.

As to the rest of your points on “other nodes, other areas” - beyond the scope.

That’s an interesting idea, but a completely different one. Your idea seems to be a solution to having a list of multiple ramps available, which is not this situation.



That would be fantastic.


Just chiming in to say that I would be thrilled to have control over color ramps outside of group nodes! Regardless of whether that’s with a ramp type socket or inputs for each control point. I’m really happy to see this proposal!

If you’re reworking the node anyway, it would be very helpful to have a factor output in addition to the color and alpha outputs, for cases where you just need a float but need to make a pattern a bit more complex than what’s practical with a float curve.


Thanks for the feedback! Just so I understand correctly - the Fac output would be adjacent to a black & white color output (potentially using the HSV calculated value of the color) from 0-1?

1 Like

Hi, first of all, thank you for working on this, you are tackling much awaited features!

I think that the direction of the proposal is good, but I’d say that it needs to consider more things when it comes to adding color stops as sockets:

1- When we connect image/procedural textures ( :heart_eyes:) or any other kind of input to the color stops sockets, how the gradient would look like? How the handle would like when it’s not a solid color anymore? Can you connect vector/math/other than color inputs to these sockets, or would give an error and make the noodle become red?

2- In your proposal, each stop is added with a vertical order and a numbered name (Color 1, Color 2, etc…). What happens if we swap/change the order of the color stops in the gradient UI? I imagine we don’t want the sockets jumping all over the place when we change their position in the gradient. What happens if we connect the same input to multiple color sockets and/or position?

3- I love the idea of double clicking directly on the color handle to choose its color, but again, what would happen in this case if there is an input connected to that color stop?

4- There are interpolation modes that give way more colors than the ones in the color stops, like in HSV Clockwise:


Would still be possible in this mode to have sockets? How would work if we connect inputs to them?

These are so far the things I think it’s important to consider when you want to implement this feature.

Along with these, I’d like to add other improvements, if possible:

  • Multi-selection of handles: currently you can select and move only one handle at a time, while it would be much more convenient being able to select and move multiple selected ones.

  • We can already add a stop by doing ctrl+click directly on the gradient, I’d add the possibility to do Alt+click on a handle to delete a stop.

  • Sometimes when gradients have lots of stops, it’s hard to move them precisely. Like with the curve node, I’d add zooming In and Out of the gradient.


The ramp creates a color value from 0->255. What do you expect using an image map for a color stop to even do? The node creates a color gradient, it’s not a … crossfade node, and at first glance it sounds like adding something beyond an RGB input value for a Stop would send calculation time to very poor, high levels.

That’s exactly what I want it to do. The top/bottom order of the inputs should match the current gradient.

I would expect nothing to happen, just as if you have an input on a rotational value - you either get control internally or from the input, not both. Same with the gradient - if you use an input value for stop positing, THAT is the value used and i don’t expect to be able to also drag the stop position within the node.

This is not a color picker node… ?

You can already zoom in and out in the window with the mouse wheel.


Well, that’s exactly why I’m asking in this forum in the draft of a proposal. And besides this, the community has asked many times through the years the possibility to input textures in specific color stops of the color ramp, actually for me this would be one the main selling point of this proposal, other than having single color inputs to appear in node groups. And maybe you’re right and it will turn out to not be possible, but since this GSoC draft is aiming to overhaul the color ramp node, i thought it was the best place to ask and propose this.

Maybe it’s not big of a deal, I thought having many vertical inputs change their oder could be irritating, maybe not too much though.

Again, I’m asking these questions because besides the function, we’ll need to visually communicate this.

I don’t know what you mean?

Zooming in the node editor to make the whole node bigger it’s not the same as being able to zoom in the gradient to gain more space between the stops.

1 Like

Yep, exactly! Just like how it works with texture nodes:

I’ll phrase it differently. If you used a picture of a rainbow for one stop, and a picture of a cat for the other stop - what visual result are you expecting at the mid point?

If the answer is “a 50/50 mix of both images”, then one would just use the 2 images in a mix node, and a black/white ramp as the mix factor. If the answer is something else, then what would it be?

I think if the input flow top/bottom doesn’t match, then it becomes very difficult to know which color is which stop position.

You gave an example image of a full-spread RGB gradient as “There are interpolation modes that give way more colors than the ones in the color stops”.

You can already choose whatever color you want for a stop… click the stop, choose the color. So I don’t understand how we currently have linear, constant, etc - and the thought is to also add “HSV Clockwise.” What does HSV Clockwise look like, as a stop interpolation, if you have 3 color stops?

Agreed, but the end result is the same (you are zoomed) and doesn’t require significant rewrite of the backend of the shader node editor.

1 Like

Clockwise and counter-clockwise already exist as interpolation methods in the color ramp node.

Nodes can be resized to a certain extent, but sometimes the ceiling feels a bit low if your ramp is really densely populated. I haven’t encountered this a lot, but lifting the ceiling for the color ramp node in particular would be welcome.

Yea, I don’t think it makes sense to connect entire images to the color ramp node. The distinction between “image” and “single color” sounds a lot like the one between “field” and “single value”, so I assume sockets would have to accept single values only.


Hey hey, just addressing some last minute feedback! Thanks again :slight_smile:

As has been said, I don’t feel like theres anything here that I could do differently than a blend mode in the Mix node can do. I do see potential benefit in possibly calculating a ramp for every pixel color on an image to the new solid color, but I feel like there could be performance implications there/could be better handled by the mix node. I may explore it, but I feel like its something that wouldnt have a ton of benefits. As such, the noodle would become red if there are any inputs that are not a solid color.

I initially thought of automatically sorting the color sockets by their position on the actual ramp, but if I implement that and do notice that it is incredibly distracting, I may opt for arbitrary, “in the order they were created” sorting instead. Because the only preview of the sockets position (other than the value of the position socket) is the slider on the fac value of the position, I don’t personally see issue in the sockets being non-sorted based on the ramp. This would also remove issues where the position value is procedurally generated, and it is set to a value that would require resorting the sockets, which would then connect that value to a socket that it should not be connected to. Without dragging along the node connections, I feel like automatically sorting could lead to these issues. (I hope this makes sense)

How I see it, the color stop on the ramp becomes grayed out, indicating that it cannot be selected. In addition to this, when the position socket of that stop is connected to something, it cannot be dragged around in the ramp preview. This could use a UI mockup, and I will be adding that to the final proposal.

This question also leads to another one: what does a stop look like when, say, a ‘variable’ float is input (e.g. the fac output of another color ramp), to which I have no exact answer at this moment. I feel like this can maybe fall in line with the color input, where the noodle becomes red when a non-float value is input.

This would operate the exact same way as it operates now. The sockets are not inherently linked to the preview, and so this wouldnt be interrupted in any way.

I will add this to the proposal, as I am one of those people who adds a ton of stops to a color ramp, so this would be a much loved feature personally :stuck_out_tongue:

Thank you again for all of the feedback, time for this final stretch!


Ok, first from my side when I wrote that I wrote it having in mind especially if we had textures connected to them, which as it was made clear, it’s not possible or in the scope of the project. But at this point, I’d say, why if we connect a color stop, we cannot select and move its handle anymore? We’re connecting the color input, not the position. I think that if you connect a color stop, maybe you can’t change it’s color anymore by double-clicking, but I feel we should still be able to select and move the handles even if their color inputs are connected. Anyway, thanks for reading and answering feedback.

True, I was expecting something like this, which surely can already be done with many different mix nodes, but I was intrigued by the possibility of doing it (example down made years ago by a user who wanted the same feature for color ramp):

Anyway, as you said it’s not something that it’s impossible to do in other ways, and it was made pretty clear that it’s outside the scope of this or nearly impossible to realize with a color ramp.

1 Like

Yeah, you would still be able to move the position if you only have the color stop connected, and vice versa. I specified that more in the proposal I submitted, just not much here :]

That is a very interesting example, and gives me a few ideas for how something like this could be implemented; it might not be color ramp but a new node or enhanced version of the mix node entirely… I may look into this for a potential future project or proposal, thanks for the example! And thanks again for your feedback! :]

1 Like

I like the idea too, in fact probably anyone who has worked some time with Blender’s shader editor has come up with their own “multimix” nodegroup : takes several color inputs, and blends/switches between them according to an input factor or index. This is possible, but not exactly ideal because 1.user nodegroups cannot have a dynamic socket count, so changing the number of input sockets means editing the nodegroup and possibly breaking other setups, and doesn’t quite give the same control over “stop” positions because interface building is too limited in this regard, and you cannot swap stops at all, since internally mix nodes are set in a certain order. Finally you’d probably also want to have a “peak control” where you can define an area around the stop where a texture is fully opaque and doesn’t yet blend into the next. Anyway, food for future thought, I won’t divert this thread further.