Hello! I’ve noticed that Color Smudge Engine brushes don’t appear to have a true opacity setting. Even when color rate is at 100, opacity acts on each dab individually, and vice versa (the default behavior of flow)
For smooth comic/illustration workflows, it would be convenient to have some sort of option that allows a more standard opacity behavior, ideally a setting that modifies color rate since opacity, as it stands, also controls smudging.
The standard opacity behavior on smudge brushes allows you to do such subtle and beautiful blending. After testing it for a bit in other apps I became really hoping this to be implemented in krita.
Paintstorm does have a lot of great features id like in Krita. Especially the double brush.
I wonder if double brush could be a way to get what you want to have a smudging brush that behaves differently, where you can increase or decrease the smudging by swapping in real time between two brushes.
[update] I stroke all the paragraph under, it was false: thanks the test of @acc4 , my workaround for Opacity was in fact only another multiplier for Flow opacity.
To workaround the lack of Opacity, I found this workaround:
This video above shows quickly how ‘Pattern’ − if used with a neutral flat grey texture and multiply − can be exploited “sort of” as a new Opacity. (Note: Sorry about the poor brush stroke demo at the end, I ran out of time to redo the video capture with a preset more ‘smudgy’.)
To testers here:
Can you test it and report if the rendering of your smudgy brushes with this opacity could give satisfaction? Of course, it’s only about the rendering; not the usability (horrible in this case, no slider on top toolbar, and we loose the possibility to texture the stroke: this is an obvious hack).
I ask this because think a report like that could really give a hint to the developers. Especially if the method here works. It can guide them how to integrate a new “stroke level global Opacity” to the Color Smudge engine (and control it with the “Opacity” slider and entry in the brush editor) and move the “Opacity” we have now to a “Flow” setting.
If this effect is not the one you look for, can you describe what is missing? what is expected?
Thanks for the workaround. Unfortunately it didn’t worked for me and I found it still unavoidable that the brushstrokes would look as if only Flow was turned on in the Pixel Engine.
If you turn off every options (except for the Color Rate which is needed for a smudge brush to have color) that affect brush’s transparency and use the texture method to emulate the opacity, you can see the texture behaves like Flow, not Opacity.
Which is odd and I’m not so sure why it happens tho. If the texture option is identical across the brush engines I guess it shouldn’t happen.
Ha, ok. Thank you for testing this more deeply. So, my workaround is just a sort of multiplier of Flow opacity. I’ll edit and update my post to correct or strike the part.
Ok one little confusion I need to clarify. The texture ‘should’ behave like Flow. It’s just that Opacity doesn’t exist in the smudge engine, and texture seems working fine as it should.
I remember using the texture like you described back in the day when the flow was overriding opacity before the william brown’s patch to fix it, and the purpose of doing that was to use texture to substitute Flow.
I was asked to reply. I was aware of this thread, just had my reason to not reply yet
Reason why I didn’t respond is because I wanted to do some research first and then do a more educated reply.
So take what I write for now with a grain of salt, I’m currently in a pinch between learning Krita codebase and art commissions, so I move slow
Problem is, I’m not sure yet if it can be done in current Smudge Engine without changing it fundamentally. That would break existing presets, which is a NO, NO.
It might need writing a completely new engine and one that would be actually two in one Pixel Engine and Smudge Engine it would be actually very close to Paint Storm Engine, at least its base features. (PStorm has some more interesting features than just that).
This is actually a very big project, and it was already on my ToDo list. Node Based Engine is even bigger. So I was thinking, that maybe I should first write complicated Paint Engine like that, to be sure I have deep understanding of PaintOps in Krita, or should I just make some improvement to old Paint Engines and then go YOLO with Node Engine
I also have to talk about it with Krita team and learn about their views.
I’m not sure yet what to do exactly and in what order, except that I should finish my current patches that I do to be able to understand Krita codebase well enough
Personally, I am more interested in node brush. So I investigated these software (black ink, ourpaint). Node brush has great extensibility, but it seems to be incompatible with what you are studying now.
CSP also has an integrated brush engine, which can also adjust brush opacity. In addition, the color mixing of Japanese software is very interesting. They mix rgb and alpha separately. If you want to consider a new engine, you can try different color mixing algorithms. (Or there are many different mix nodes for customization in the future node brush…)
Don’t worry if Node Engine supports these features or not, depends of the implementation of the Engine not if it uses Nodes or not. Mine will support both of these featrues. If it wouldn’t I wouldn’t even bother making it xD
Can you show me example of that you are refering to? I don’t remember any particularly interesting blending in CSP or maybe I don’t understand you (or my memory has holes which might be true)
Haha, I just think they will be difficult, so other developers have avoided them. I hope you can succeed!
First of all, csp has three different color mixing modes: blend, running color, and smear. “Running color” has a blur parameter, so it is similar to paintstream’s brush engine. When its parameters are adjusted, it will also be close to krita’s “dulling” and “smear”.
“Blend” and “smear” are two other mixing methods, among which smear is a new blend way in 2022, and its color is very bright. I guess it does not mix alpha .
For color mixing parameters, many software use a parameter to mix rgb and alpha at the same time, which leads to more low color saturation at the beginning of painting. Japanese software (sai, csp) generally has two parameters, one of which is responsible for alpha mixing, and can also simulate the feeling of “adding more water to the brush”.
100 Amount of paint 0 Density of paint
0 Amount of paint 100 Density of paint
In addition, it can also be used with double brush to simulate the color mixing of watercolor.
Naaah, I think they avoided image brushes because it was not interesting for them to code and about temporary layer that enebles opacity setting they just didn’t know is needed before they designed the system. Krita covers both of these features already so I’m covered
OH! This mixing looks very interesting I will have to look into that!
I think this can be achieved in krita, and clone brush engine has already achieved this. If the cloning source is set below the nib, the cloning brush will achieve a smudging effect. Of course, there is no such option in the cloning brush engine.
I tried to change the clone brush engine indirectPainteCompositeOp() to COMPOSITE_LPHA_DARKEN and achieved the desired effect, but in COPY strange behavior will occur in the COPY mode. If the problem in COPY mode can be solved, this feature can be implemented. However, due to my limited coding ability, I don’t know how to solve it.