Idea: New brush engine sensors

[hulmanen]

I’ve had some trouble with brush tips feeling different at different sizes, probably because of how the filtering of the scaling algorithm works. Small, textured tips feel “scratchier” than the same tip at a larger size. Thinking about how to work around it, it occurs to me that if we could use “brush size” to drive e.g. flow , we could compensate for this.

So how about adding some new sensors to the different brush settings? “Size” at least seems like it would be useful, possibly “Opacity”, “Flow” etc as well. Apart from my use case, it could simplify making brushes where you want to have the same pressure curve for different parameters - you could just set the curve for e.g. “opacity” to what you want, and then if you want to reuse that curve, you would enable the “Opacity” sensor under the relevant parameter. You could even make further modifications to the curve this way.

Of course there’s potential for feedback loops here - you wouldn’t want to allow a “size” sensor under the “size” parameter, for example. And you’d need to find a way to avoid cross-linking of different parameters. I don’t think that’s insurmountable, though.

[AhabGreybeard]

@hulmanen

you wouldn’t want to allow a “size” sensor under the “size” parameter, for example. And you’d need to find a way to avoid cross-linking of different parameters.

I’d like to try that because there could be some interesting oscillation effects.

[Takiro]

Sounds like an extension to this

Bindable brush settings - determine the value of a setting by the value of another

Okay this is a thing I am thinking about for years now. It would be cool when you could bind a setting to another of the same brush preset. Consider the following use case (i actually have) : You want to create a brush to create a fur like pattern when painted. One of the important properties would be that the stroke fades out by getting smaller over the length of the stroke. This is of course easy. You open the preset, go to size, check fade, enter a reasonable value for length, set the curve…

[TheTwo]

First, I don’t think the ones you mentioned should be absolute values (like size fixed at 100, that’s a nightmare)
So it should be a relative value like “50% of size”. 50% is a combination of the curves of size
I think mypaint brush has a “custom” project, set the curve in it, it may be the desired effect.

[hulmanen]

@Takiro: yep, seems like basically the same idea.

@TheTwo : yes, definitely the values need to be normalized. Right now it shouldn’t be a problem, since most values already fall in the 0-100 range and the brush size has a maximum of 1000.

[Deevad]

@hulmanen

[…] Apart from my use case, it could simplify making brushes where you want to have the same pressure curve for different parameters […]

Hey, just a thought about this; buttons to copy/paste the curve maybe?

Fig: A mockup with proprietary icons found on duckduckgo search

[Grum999]

Hi

@Deevad

Fig: A mockup with proprietary icons found on duckduckgo search

As you’re running an a Debian derived distro, you might found a lot of useful icons in /usr/share/icons/breeze/actions/16
(or if breeze theme is not installed, you might found them in one of current installed theme)

Grum999

[Deevad]

Thanks for the tip! I’ll save the path on my bookmark.

[Deif_Lou]

(sorry, a bit of offtopic follows)

@Deevad

Hey, just a thought about this; buttons to copy/paste the curve maybe?

What I would like is:

• making the curves a new resource type. That way one can store them.

• after point 1 is implemented, in the brush editor, instead of having a whole page for the curves, I would suggest having just 1 row with:

  • name of option
  • check box to enable
  • main slider
  • a tool button with dropdown arrow. If one clicks the button, a curve editor dialog appears. If one clicks the arrow, a list of curve resources appear.

  But I guess that makes sense in a tool options ui redesign, because the rows may look odd with the current one.

[Rakurri]

I would looove this! Sometimes I jump back and fourth copying the excact values of curve points. It takes a lot of time so I almost tend to experiment less with masked brushes because of it. This would allow me to experiment much more comfortably

[hulmanen]

Copy/paste, and @Deif_Lou 's idea about curves as a resource in particular, would be quite neat. It’s a little bit different from what I have in mind, though. The primary idea here is to be able to automatically drive different attributes based on things we can’t access now, but the secondary benefit that is close to your idea is to be able to reference different attributes without having to copy the curve at all.

So if I changed the pressure response curve for opacity, any attribute that referenced that would automatically now respond to the change. Also, if I had several sensors affecting opacity, anything referencing the opacity attribute would take as input the combined effect of the relevant sensors, not just “pressure” or “speed” etc. Further, the user could apply a new response curve on top of this opacity input, just like with any other sensor, in case tweaks like cutoffs or whatever are needed.

Am I being clear here? Or should I maybe make a mockup?

[Deevad]

I think I have the idea, but I can’t resist asking for a mockup as it would really clear any confusion and be a big plus to this topic, imo.

[EyeOdin]

Like node hook ups?

[Deif_Lou]

Indeed this seems to be more well suited for a node system than the current system. I mean, in a node system this would feel very natural and out of the box.

[hulmanen]

@EyeOdin @Deif_Lou Yea, I’m all for node-based brushes, and yes, this is kind of going in that direcion. I don’t think we need to implement a node system just for what I’m proposing, though.

I think it’s pretty clear what I meant but anyway, just in case, here:

Now I don’t see myself needing to connect most of the available brush attributes, but I’m sure someone will want to have access to pretty much everything in the box on the left. That would make the list of sensors very long, so I propose adding the ability to add new sensors to the default list, by adding a small “+” at the end of the sensor list.

We’d need to prevent loops and tell the user why they can’t do what they want if they try to create an “Opacity > Size > Opacity” loop for example.

Having said all that, actually it seems to me like of these available attributes, the ones that the user changes on the fly while painting are a little special since in actual brush use, they do not map between 1-100%, but rather 1-100% of whatever base size, opacity etc. the user has chosen. So in that sense I think already just adding this feature for:

• Effective size
• Effective opacity
• Effective flow

would go a long way. The rest of the attributes do not, as far as I can tell, actually need to be dynamically referenced, their curves can just be manually copied. (or, hopefully at some point, non-manually ) But right now, if the user needs access to the above attributes, there is no way to do it.

Edit: Example: I would like to increase flow as the effective size of the brush decreases. This can not be done right now.

Probably there’s some attribute people change on the fly that would also be good to include - brush angle, maybe? But I don’t think this needs to be as complex as allowing all the connections everywhere, as cool as that would be.

[Grum999]

@Deif_Lou

I mean, in a node system this would feel very natural and out of the box

A node system for brush might need a new brush engine implementation rather than trying to convert current engines, for following reasons:

• Current brush engines works pretty well; doing a conversion to a node based system means probably a lot of regression and clearly, as brush current brush engines are probably the most important thing in Krita, I don’t think that’s a reasonable idea

• Doing a conversion of existing bundle -official and personal users owned brushes- might be hell and there’s a risk that (for some) brushes results are not the same than before

• A node based brush system will probably have lower performances than current brush engines:
  – Currently: everything is hard-coded, optimized, compiled
  – Node system: (entire) tree node have to be executed each time something have to be drawn in canvas, code is not entirely compiled anymore (nodes calculation can be compiled, nodes browsing will be an interpreted part)
  – By nature, a node system can be from simplest to most complex node tree and when people will start to create huge nodes tree with complex calculations, maybe performances for some brushes will be crapy

After it could be an interesting thing to have:

• For brushes creators, no limit to brush creation
• For developers, implementation of a new node calculation type could be easier

Grum999

[Deif_Lou]

Well, I’m not saying that a node based brush engine should be implemented. I’m just saying that this kind of workflow seems more natural in a node based system.

Currently the brush engines work in a somewhat linear fashion, one step after another. As soon as you introduce references/dependencies from one step to another you end up having kind of a graph, which would resemble a node system, but in code. But I think a graphical node-based brush engine is a larger project to be discussed in another thread.

Dmitry is working on remodeling the brush editor internally. I think the feature proposed here would be easier/cleaner to implement after those changes. The feature itself shouldn’t make the engines slower, but one thing I think is important is to come up with a generic design that could be easily extended if needed in the future without having to reimplement the system.

[EyeOdin]

for me copy paste would be more than enough for now. referencing curve objects I donno.

[hulmanen]

It’s just that some things simply can’t be done with the curves alone, like compensating for brush size. But then again, maybe I should instead be pushing for a look into the brush tip filtering algorithm used, so the average output would remain the same regardless of size.