The only thing I didn’t check is the “dragging” issue @RamonM mentioned. I guess I need more info about that, because I don’t really understand what the problem is.
PS:
Btw, AppImage packages are now split into two. One AppImage -debug-dk6 is the build with ASAN, which may help finding bugs, but it is about 1.5x slower than the real build. The other one, -dk6, is the build without any sanitizers, so it should run at the full speed.
There’s still an issue with the lightness strength slider, which is kinda visible in this image at the top, but I need to create a better example. Basically, if you have a stroke with a lightness brush, but not the lightness strength option enabled, and then another stroke with the lightness strength enabled, you get weird results:
The error at the bottom here is most prominent, but the overlapping strokes seem weird as well.
I haven’t looked through the code thoroughly yet, to see how the heightmap portion of the stroke is implemented, but I think there are two different issues displayed in your example.
The first is that it appears the Lightness Strength option on the second stroke is applied properly where there isn’t already a lightness stroke beneath it, but not when it’s over a previous lightness stroke. What you should expect to see is the lightness values of the first stroke bleeding through the values of the second stroke, so you can still see the first stroke through the second one, and the height lines from the second stroke should be just as faint over the first stroke as they are over the background pattern. Currently where they overlap, you see the new heightmap only, but it’s stronger than where it’s not over the first stroke, but not as strong as the heightmap on the first stroke. If you could see the old heightmap, it would look like you’re painting naturally over a previous stroke, but here, because the lines from the second stroke are all you see, and they don’t match the strength on the other parts of the stroke, it just looks really unnatural. I suspect this is just an issue with whatever blending mode @dkazakov used for writing each stroke onto the heightmap.
The second issue is the visual bug at the bottom of the image when the stroke approaches the edge of the background pattern. I’m pretty sure that’s a separate issue from the first, and probably not related to the lightness strength option. I don’t know what’s causing it, though. Hopefully it’s an easy fix
I wish I had time to really test this out, but currently am working on other things, and don’t want to mess with my Krita settings. I’m looking forward to this update being finished, though, and love the work @dkazakov has been doing so far!
First impression is very good, i am feeling like discovering new roads to be explored. I have created some prototypes to test different things.
Only one thing is annoying, i don’t know but sometimes when i am painting i have this glitch
The stroke is yellow but is erasing some parts in the layer so i can see the sketch behind. I solve that duplicating the layer and painting there. Then i collapse, but is quite random. i need more testing
Yeah, that’s the ‘prominent error’ that shows up in my gif as well. Voronwe called it a visual bug, but it’s not, it’s pixels unaffected by the previous stroke being turned transparent while the current stroke is written there. Proly related to the lightness map as well but in a different way from the blending of two lightness strokes.
Krita 5 will have lot of good things, would be people interested in testing with these brushes? i think the more testers the more pulished the feature can arrive to Krita 5 so i can share the brushes even with this ugly icons or a bit better… Time is important here too.
Thanks a lot for your feedback! I think I’ve fixed the issues you mentioned how. The updated packages are linked below
There’s still an issue with the lightness strength slider
I think I have fixed the issue. I have changed the hightmap’s blending mode from alpha-darken to over, perhaps it would help. Could you check it please?
The second issue is the visual bug at the bottom of the image when the stroke approaches the edge of the background pattern. I’m pretty sure that’s a separate issue from the first, and probably not related to the lightness strength option. I don’t know what’s causing it, though
Yes, the problem was in handling undo/redo for the interstroke data. I think it is fixed now.
The stroke is yellow but is erasing some parts in the layer so i can see the sketch behind. I solve that duplicating the layer and painting there. Then i collapse, but is quite random.
I think it was exactly that undo/redo problem I fixed The symptoms are the same.
I am testing now DK7 and updating the brushes. Really interesting to see that Neutral point is Working and also Contrast. I need to test Brightness. for the moment no problems with “erasing” issue.
The color accuracy is important and this is why i use neutral point, brightness and contrast , to make more accurate or not. (sometimes accuracy is not needed) But if you color pick a color you want to get the color you pick usually
Performance im a DinA 4 is quite good to be in testing mode.
Afair, neutral point doesn’t do much difference in ColorSmudge engine, because the brush is explicitly normalized before painting. Though the normalization algorithm is not as good as the one of the neutral point manual setting, so it is still good to keep the value set “somewhat correctly”.
I will recheck it now, but the original idea was that the brush should always be normalized, otherwise the color value will converge to either black or white very quickly. And you cannot achieve such precision by the manual slider.
I actually though of making a GUI option for “Auto neutral point” but I did’t implement that in the end.
Yes, I remember testing this type of brushes back then and really struggled with the symptom that the color gets far different every time I colorpick its strokes. Use alpha channel in brush tips, or add an overlay tip - #94 by acc4 And it’s not a good thing. I really dislike the idea of making the brush ‘engine’ easily create happy accidents, because the result should come out in the expected way. That’s the whole point of having a tool, which is to help visualize what people have in mind.
I’m not sure I understood the normalization stuffs, but I hope I don’t have to deal with those problems with Krita 5.
That is the reason why i want to keep the 3 parameters active but also the normalization active. Maybe i explined bad myself?. As it is Right now in DK7 is perfect for me. i love it.
I’m not too experienced with smudge engine tbh, but the RGBA brushtips do their job and feel amazing. I can’t wait to test them out with height and overlay pattern modes, once both of these get merged
i don’t want to overload you
