It doesn’t really make sense to me. The purpose of exposing the ramp to a group node is that the value used to look up a color in the ramp can stay inside the node group. If from inside the node group it’s as if you are just receiving a color, that’s not possible.
2 Likes
Of what use would it be, collapsed by default? And to what benefit? You’d have to open it constantly.
For the same reason that the principled bsdf has subsurface, specular, transmission, coat, etc. collapsed by default – to keep the form factor of nodes more managable.
2 Likes
BSDF parameters that are completely different from each other, and have different functionalities in ways they combine. Often, a shader doesn’t even use all of the inputs.
No one uses a ramp node without color chips. Not a similar comparison.
While making them collapsible makes sense as it could get rather large with additional stops, I would assume the node would start with only two as it does currently. I don’t really see that as unwieldy enough to require being collapsed by default—I’d estimate the vertical size of the node to be somewhere between the noise texture and brick nodes.
1 Like
Given that you can get an insane amount of chips into the ramp using the color picker, of course it should be able to be minimized or whatever.
But everything hidden by default for two colors? No.
1 Like
Of the countless Blender tutorials I’ve watched, 90% of the time I see the user moving the black and white color chips’ position to create more contrast or limit the min and max values going through the color ramp node – not adding and manipulating multiple colors.
Often people use the color ramp node because it’s more intuative than the map range node, which analogously, has all the inputs that you’d like to see added to the color ramp node.
2 Likes
Yes, and for that use - one might not need inputs in the first place. For NPR shaders, people do more than a black/white chip on a regular basis.
The user can still Cntl-H a node if they want to see less, it’s already a feature.
Pencil+ materials are done this way, it works nicely:
1 Like
More of a reason why it should be collapsed by default.
Obviously we’re all passionate about our different needs and want what’s best for ourselves.
You say, “just ctrl+H” and I say, “just uncollapse”. Both are annoying if you have to constantly do them.
I’m optimistic that someone smarter than both of us will find the right solution for the community at large.
Here are some color ramps from my most recent projects:
That isn’t to say that I don’t have simpler color ramps, of course, but there are definitely use cases for 20+ stops on a color ramp. I use at least two color ramps of that definition in every project
5 Likes
What percentage of your color ramp nodes are like this in a given project? Or per day? I’d wager a lot that it’s around 10% or less.
No, it’s about 80%, actually. As I said, every material I make has at least two ramps that look Ike this.
I understand you use these in your shader editor, but how many ramps do you use throughout Blender, i.e the compositor and geometry nodes? Unless you’re only working narrowly on shaders all day, you and many others use the default color ramp everywhere more than the examples you prodvided.
I don’t believe you’re being deliberately obtuse, but I’m sure you have to admit that your specific use case isn’t that of a majority of people.
Speaking for myself: nearly every shader includes at least one ramp. Some include 3-5.
In compositing, none. Geonodes, practically none…if ever?
1 Like
I use no ramps in either.
I really don’t… it’s either highly complex ramps like those or multi stop black/white ramps, exclusively for shaders. Very few of my ramps use two stops, although there are definitely some.
I never said it was 
1 Like
Could this involve redoing the “Material” tab in the properties editor? As is, it is hardly unusable to create materials more complex than mere base color changes. A node group input approach, like it is with geometry node modifiers, is vastly superior.
Just like with geometry nodes, the user could select a node group in the material tab, and adjust it’s inputs. That’s it. For example: Imagine if all the user had to do to create a simple PBR material, is just select a simple PBR node-group in the materials tab, and directly link to textures (Base, Roughness, normal, etc.) from there.
This means, that, like geometry nodes, all those socket types (String, boolean, texture, object, collection and etc.) have to work for shader node-groups as well.
2 Likes
Also I would add a boolean socket input for every stop (together with color and position) so that you can disable the stop. This way you can change the number of stops per group.
I believe that extending the scope beyond the node editor into properties - even if accepted as a task - increases the likelihood that the overall project will not be feature complete within the timeframe of GSOC.
And as a result, the overall project will be semi-permanently shelved as “wip unfinished” as so many other good GSOC projects have been.
2 Likes
This thread has been busy! I am very sorry for any delay in updating my proposal, my personal life has been busy.
I have chosen to overhaul the color ramp node itself, instead of creating a dedicated ramp socket type. Creating a dedicated socket type is something I fear would be beyond the scope of a GSoC project, considering the various design implications it has from all fronts, in addition to it implying the necessity of various other sockets. I would still consider the project as I overhaul the color ramp node, so that my additions can be as prepared for such a new socket should it happen somewhere down the line (I may still tackle it outside of GSoC).
I am excited to hear your feedback on these new changes, thank you all for the feedback thus far!
3 Likes
Honestly, I don’t know who and what for need this, but this looks like thing what have more cost than benefit.
- First of all, you can not have UI of gradient and sockets of gradient points at the same time.
- Next, sorting of points for positions totally cuts idea of using UI.
- How this extends options to user to use this as interface of node groups? As i see, now node group need to have 10+ new sockets just to let to user to input new Color Ramp info into node groups. User still can’t add another one color-point to Color Ramp. And i am not sure if just sampling of color by factor is the main function of Color Ramp and that users cannot implement the same sampling node group with 10+ sockets already today.
- Latest one, there is RGB Curve and Float curve with approximately the same goal as Color Ramp, should this nodes have the same sockets?
There is still no answer on simple question about how modern thing from Geometry Nodes should be added to shader nodes. I’m okay with just simple description of details of this process.
Compositor, Geometry Nodes, Shader nodes… Each system has its own implementation. Each have its own code base, evaluation specific, and some of them use completely different languages.
Not sure i see if you planes to changes anything else except of Shaders.
But even shaders requires some of code refactoring just to support enumerations in code of building shader from nodes. And there is still issues with ui and field interfacing.