← All ideas14 Jun 2018lsscppOpenShading and TexturesCompositingUser InterfacelsscppAnthonyGuiziouBlenderonBoxyXYZBulatFinnster_FudushaeGOMGorgiousKickboxingBananaLauloqueLuis.BurdalloMrJomoNick2321SpectralVectorsSymstractThe_Kalaakaaraasheagent_53ath0rusbestelixbnzscanapylbbdalekzedanial-mahdi-soozanidesksonmarsdestrosvetdevanshutak25fructdwgraehugreywindshperticaratijanek.bernzenmanuelgrad.atmasinisa89mipetr127nekketsukyoujino.mangoldradzo73raulgaletsrengglirex_kungolosseanansilexsimonstoschuslykdrakosng84txoultrablasterunizenx-zayyann
To stick with the left input, right output paradigm, perhaps this should be adjusted so the ramp is displayed vertically.
5
L
Lauloque
Agree. Especially when there are many sliders, the inputs will quickly saturate the space anyway.
I think there is a way around this with the sliders's ID value, it could work kind of like the ID mask in compositing: choose the ID of the corresponding slider in order to access its color input.
But I can't find UI for that without making the color ramp a huge messy node...
o
o.mangold
Nice. The Vector Mapping Node has the same issue. For this one I would also wish that the values for Location/Rotations/Scale could be fed from inputs.
3
A
AndySellers
@o.mangold:
The Object Info node can do some of this, i.e. giving vector values for Location. Is that what you're thinking of?
@andrewsellersm90:
No, what I mean is the mapping node can do custom coordinate transformations (allowing to specify displacement, rotation and scaling). But the parameters for this operations are just edit fields which cannot be connected to any inputs.
o
o.mangold
@:
Yes, sure, I could. Actually I could provide an endless stream of requests and proposals. There certainly is no lack of ideas. But I fear if I get started with that I won't be able to stop :)
a
agent_53
Personally the way I would work it is that each handle has a color and position input added to the stack, akin to the way a group node will get bigger as more input values are plugged in.
Certainly the color part needs to add access outside the node itself, in my projects I use a lot of procedural materials that I then make into groups so that I can easily make multiple materials of the same type with different colors, and the Color Ramp currently hamstrings that, because individual colors can't be linked to the group input node.
Sticking to left input right output system, we can also have something like this, the list for the positions of the flags will grow and shrink as flags are added or removed.
1
v
valentinwn
1
m
mistajolly
@valentinwn:
Think this is unlikely to work well due to the way that the color stops are stored and added. If you move a stop and it changes position, how should the list change?
1
v
valentinwn
Since the list can not change, the operation remains the same as the original one. There is simply a list of color stops. The one above could very well be at position 1,000 and the one below it at 0,000
French> English: sry for translation
s
simon.p.heggie
Why not expose the position too? We can use that to create pallet cycling effects. This is perfect for real-time flow effects in shaders.
l
lsscppAuthor
Actually, I don't know what would happen if a non-numeric value (e.g. a texture) feeds those bottom inputs. Maybe it should act as a sort of multiple-inputs MixRGB node set to 'Mix'?
14 Comments
To stick with the left input, right output paradigm, perhaps this should be adjusted so the ramp is displayed vertically.
Agree. Especially when there are many sliders, the inputs will quickly saturate the space anyway.
I think there is a way around this with the sliders's ID value, it could work kind of like the ID mask in compositing: choose the ID of the corresponding slider in order to access its color input.
But I can't find UI for that without making the color ramp a huge messy node...
Nice. The Vector Mapping Node has the same issue. For this one I would also wish that the values for Location/Rotations/Scale could be fed from inputs.
@o.mangold: The Object Info node can do some of this, i.e. giving vector values for Location. Is that what you're thinking of?
@o.mangold: the natural consequence of your request in this proposal page, is to make another proposal: blender.community/c/rightclickselect/TFbbbc/
@andrewsellersm90: No, what I mean is the mapping node can do custom coordinate transformations (allowing to specify displacement, rotation and scaling). But the parameters for this operations are just edit fields which cannot be connected to any inputs.
@: Yes, sure, I could. Actually I could provide an endless stream of requests and proposals. There certainly is no lack of ideas. But I fear if I get started with that I won't be able to stop :)
Personally the way I would work it is that each handle has a color and position input added to the stack, akin to the way a group node will get bigger as more input values are plugged in.
Certainly the color part needs to add access outside the node itself, in my projects I use a lot of procedural materials that I then make into groups so that I can easily make multiple materials of the same type with different colors, and the Color Ramp currently hamstrings that, because individual colors can't be linked to the group input node.
i.imgur.com/QxAggCH.png
Sticking to left input right output system, we can also have something like this, the list for the positions of the flags will grow and shrink as flags are added or removed.
@valentinwn:
Think this is unlikely to work well due to the way that the color stops are stored and added. If you move a stop and it changes position, how should the list change?
Since the list can not change, the operation remains the same as the original one. There is simply a list of color stops. The one above could very well be at position 1,000 and the one below it at 0,000 French> English: sry for translation
Why not expose the position too? We can use that to create pallet cycling effects. This is perfect for real-time flow effects in shaders.
Actually, I don't know what would happen if a non-numeric value (e.g. a texture) feeds those bottom inputs. Maybe it should act as a sort of multiple-inputs MixRGB node set to 'Mix'?