I made a post about this a long time ago, the idea is to create a new type of variable (gradient)
4 Likes
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.
4 Likes
Disagreeā¦
That would be fantastic.
2 Likes
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.
8 Likes
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 ( 
) 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.
2 Likes
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.
2 Likes
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
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.
2 Likes
Hey hey, just addressing some last minute feedback! Thanks again 
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 
Thank you again for all of the feedback, time for this final stretch!
3 Likes
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 2.it 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.
2 Likes