I feel culprit for this bug, or non-finished feature because it's me who wrote the document http://www.davidrevoy.com/article107/textured-brush-in-floss-digital-painting , with wrong informations on 'How I guess it works' chapter. I obviously didn't studied it enough, or missed informations. So 1 years and 2 month after, I decided to investigate again in depht, and see what Krita is able in order to finish this amazing feature. ( The feature is available since 2.5 and still sleep because -I guess- the result is not what user expect. ) == 1) A better test file == * Illustration (a) : http://i.imgur.com/Btm0Q11.jpg I worked on having a better test file ( I'll add it in attachment the texture + the linked *.kpp preset ) than my previous poor binary black and white 'checker'. It helped me to figure-out how the actual parameters works on Git master. The 'Texture-tester.png' pattern contain blured dots , from 0 to 100% value ( ref: Illustration a ). I also drew on it a 3D representation to understand the Cutoff parameter in a visual way. == 2) finding the right setting to attribute a pressure dynamics == The target is to give to the user the feeling of having a tool who affect the grain of a texture. For reference , I did test to the root and took a photo of 3 traditional art tools and the way they react to a paper texture here. ( Ref : http://i.imgur.com/bZtywuN.jpg ) So , doing high pressure on the stylus should give the feeling to crush all the texture and deposit a lot of 'pigment' on the canvas ( and so affect all the brighter value on our test-texture ) . In opposite , the lower pressure should only affect the peaks ( dots in black our test-texture ) to give the user the feeling to only touch delicately the texture, and deposit 'pigment' only on the micro summits of it. Fortunately , the feature exist at 90% I would say in actual Krita : when -in texture panel- the mode is "Mask Out" , and the check-box "inverted" is checked , moving manually the little 'black' pyramid slider from right to left already select the value range to affect. If this value/data could be linked to a pressure dynamic, the 'textured stroke' feature would work. This illustration under shows it : illustration (b) : http://i.imgur.com/n5IujLP.jpg
Created attachment 76686 [details] the test-texture in *.png , and a simple *.kpp preset to test it
I guess I have some idea on this topic, but I need to elaborate it a bit first... =)
Heh, I was looking into your samples and understood that we have one more problem with texturing :) We are currently multiplying the texture with the dab, but we should subtract them actually! Your illustrations (especially the one with 3D-version of a texture) show it clearly! Here is an example of the difference: http://wstaw.org/m/2013/01/25/plasma-desktoppN2412.jpg Here is a small patch to show this: http://paste.kde.org/656054/ And here is a pattern I used for testing: http://wstaw.org/w/1DpU/ Of course, we also need the pressure sensor for this, as you say in the bugreport :)
The same with pressure: http://wstaw.org/m/2013/01/25/plasma-desktopw22538.jpg
I'm not sure that multiplication is always wrong -- it could be that some patterns work better with multiplication, others with subtraction. I got the multiplication from the gimp painter source code. Maybe we can just make it another option.
Check also bug https://bugs.kde.org/show_bug.cgi?id=288696. The last remaining real issue here was implementing a wash mode for the textured brush. This means that the texture get applies to the whole stroke in one go, instead of to the dab. That prevents the texture getting lost through superimposition of lightly textured dabs. For this, the compositor needs to be able to apply the texture when composing the indirecting painting paint device in the project, and that was something I hadn't solved yet when I was last working on it.
Oh, and one final thing, in the origin/krita-indirect_painting-rempt branch, we'd started to make the pressure filtered through a curve. That might still be something we'd want here. A patch to switch between multiplication and subtraction can go in directly, as far as I'm concerned.
Git commit bba9188e9e8fb7bece4d863b81c93d87b942c363 by Dmitry Kazakov. Committed on 25/01/2013 at 10:33. Pushed by dkazakov into branch 'krita-textured-painting-kazakov'. Added simple implementation of the texturing with real paper effect M +3 -0 krita/plugins/paintops/defaultpaintops/brush/kis_brushop_settings_widget.cpp M +1 -0 krita/plugins/paintops/libpaintop/CMakeLists.txt M +1 -1 krita/plugins/paintops/libpaintop/kis_dab_cache.cpp A +34 -0 krita/plugins/paintops/libpaintop/kis_pressure_texture_strength_option.cpp [License: GPL (v2+)] A +38 -0 krita/plugins/paintops/libpaintop/kis_pressure_texture_strength_option.h [License: GPL (v2+)] M +14 -3 krita/plugins/paintops/libpaintop/kis_texture_option.cpp M +3 -1 krita/plugins/paintops/libpaintop/kis_texture_option.h http://commits.kde.org/calligra/bba9188e9e8fb7bece4d863b81c93d87b942c363
Created attachment 76703 [details] Four presets showing the work of code in krita-textured-painting-kazakov branch Hi, David! Could you please test the draft implementation of the textured painting in krita-textured-painting-kazakov branch? I've implemented it basing on your illustrations, but just in a bit inverted approach. Now the texture is not a map of _peaks_ on the paper, but, in reverse, a map of _caves_ in it. That is the texture shows the points of canvas where the ink has difficulties to get into. So the user should use more pressure to put ink into these caves. I took two sample textures of the realworld paper and tested the algo on them: http://wstaw.org/m/2013/01/25/plasma-desktopW27284.jpg Could you please test it and tell you word about it? In attachment you can find an archive with four presets, containing these realworld paper. About the changes in the UI: 1) Now there is a Strength curve, that maps the pressure of your pen into the strength with which the ink is pushed into the "caves". 2) I guess, you needn't use Strength and Cutoff sliders, because, their functionality is accessed via that curve (?)
The strength slider can be replaced by a strength curve, but not the cutoff slider, since that has several other uses, see the combo dropdown. Please, when working on this issue, do not disregard the other issues I've noted * the need to offer a per-stroke texture application * don't drop the multiplication option, since it is, in fact not wrong: it only seems wrong because we do not have a per-stroke texture application.
Just to add here what I already said on IRC for logs; I'm totally satisfied by the actual feature with the change of Dmitry, Thanks ( and nice screenshot you made, and the preset for testing are good too ) . The feature works perfectly about the artistic result, and I'm able to setup my brush and 'get' the effect I'm looking for. This could stay as it is now, in my opinion . I have sufficiently of things to explore in the current configuration, all a new 'world' of tweaking is opening : I have to work to propose better default 'pattern' to Krita. I suspect it will attract a lot the speed-painters. ( my test, so far : http://fav.me/d5snu4g ) My only more wish would be to have similar feature affecting the "Smudge Color" brush engine. That would be the last step to make Krita 2.7 equally featured as was (R.I.P.) Gimp-painter 2.6 ( in Gimp-painter 2.6 : 'mixbrush' -the equivalent to Krita's smudge color with 'dulling'- had a similar 'texture' option. )
I continued to test in depht, also I started to do optimised textures for the feature ; the pattern delivered actually with Krita are a bit a mix of a lot of things ( GPS , Mypaint, Chaos&Evolutions, various sources ) , most of the time not adapted. So, I 'm working on normalizing them, ( B&W , black pixel to white pixel, with most pixels in 50% value ) removing duplicate, and make a cool pattern resources. During my test , I saw 2 bugs related to the 'texture' feature : 1) Having PNG in greyscale mode inside the 'pattern' folder : They will launch, show thumbnails in the brush editor , but crash Krita on click on the thumbnails. ( They can be prohibited to ease life, sRGB one are fine ). 2) An annoying one : It seems each preset of 'pixel brush engine' ( even the one without a linked texture, or option activated ) load a texture after being selected via the preset selector. Result ; if you start-up Krita, and select a 'pixel-brush' on the preset docker, you have a extra 1 or 2 second 'freeze of loading' . Especially if you have big pattern in folder ( not necessary linked to the active preset ). It's feels like if Krita tries to create the mask for every texture available when a preset with 'pixel brush' is selected. Selecting a smudge color brush on opening is instant in comparison.
About crash 1: For now you can workaround it by rerunning Krita :) On the next run after adding the pattern it works right :)
Git commit 6ed82cac158e8372b8f7240a3cec6fc2c9ced21b by Dmitry Kazakov. Committed on 26/01/2013 at 08:18. Pushed by dkazakov into branch 'krita-textured-painting-kazakov'. Added an option for switching between Subtract and Multiply modes of the texturing 1) Added a switch Subtract/Multiply 2) Removed the Strength slider. Now the curve is used for it (backward-compatible). M +- -- krita/plugins/paintops/defaultpresets/paintbrush.kpp M +35 -1 krita/plugins/paintops/libpaintop/kis_pressure_texture_strength_option.cpp M +3 -0 krita/plugins/paintops/libpaintop/kis_pressure_texture_strength_option.h M +25 -22 krita/plugins/paintops/libpaintop/kis_texture_option.cpp M +6 -1 krita/plugins/paintops/libpaintop/kis_texture_option.h http://commits.kde.org/calligra/6ed82cac158e8372b8f7240a3cec6fc2c9ced21b
Hi, David! I've changed the settings xml format a bit, so if you have already managed to prepare some presets, you'll have to edit them a bit: 1) You need to set the Texturing Mode combo box to Subtract (it defaults to Multiply for backward compatibility) 2) You need to reconfigure (and activate) the Strength curve, because it will probably become disabled for those presets. The rest will be the same.
Git commit f3012ab7e5b03f5e2da48243ca9047327c753da0 by Dmitry Kazakov. Committed on 26/01/2013 at 11:16. Pushed by dkazakov into branch 'krita-textured-painting-kazakov'. Added texturing capabilities to other dab-based paint ops That is to: 1) Duplicate Op 2) Color Smudge Op 3) Hatching Op M +4 -4 krita/plugins/paintops/colorsmudge/kis_colorsmudgeop.cpp M +2 -3 krita/plugins/paintops/colorsmudge/kis_colorsmudgeop_settings_widget.cpp M +0 -3 krita/plugins/paintops/defaultpaintops/brush/kis_brushop.cpp M +1 -2 krita/plugins/paintops/defaultpaintops/brush/kis_brushop.h M +2 -6 krita/plugins/paintops/defaultpaintops/brush/kis_brushop_settings_widget.cpp M +2 -0 krita/plugins/paintops/defaultpaintops/duplicate/kis_duplicateop_settings_widget.cpp M +- -- krita/plugins/paintops/defaultpresets/colorsmudge.kpp M +- -- krita/plugins/paintops/defaultpresets/duplicate.kpp M +- -- krita/plugins/paintops/defaultpresets/hatchingbrush.kpp M +2 -0 krita/plugins/paintops/hatching/kis_hatching_paintop_settings_widget.cpp M +3 -0 krita/plugins/paintops/libpaintop/kis_brush_based_paintop.cpp M +2 -0 krita/plugins/paintops/libpaintop/kis_brush_based_paintop.h M +10 -0 krita/plugins/paintops/libpaintop/kis_brush_based_paintop_options_widget.cpp M +1 -0 krita/plugins/paintops/libpaintop/kis_brush_based_paintop_options_widget.h M +1 -1 krita/plugins/paintops/libpaintop/kis_dab_cache.cpp M +1 -0 krita/plugins/paintops/libpaintop/kis_texture_option.cpp http://commits.kde.org/calligra/f3012ab7e5b03f5e2da48243ca9047327c753da0
As I said on IRC, the new changes are fantastic. I can't wait to block a bit more of personnal time after painting for my clients to investigate more painting hours with it. I also published my work on renovating the pattern : It's 25 *.png pattern , in 9,2 MB : * download : http://www.davidrevoy.com/data/documents/2013-01-26_Krita_texture-pack1.tar.gz * infos : http://www.davidrevoy.com/article156/texture-pack-1 My idea would be to propose to ship them in Krita, the 'deevad_' prefix of the filename could and should be removed. Also, I would suggest to remove most of all older pattern : most of them are too low res, not normalised , and doesn't produce good effect. As 2.5 and 2.6 have the 'texture' embeded and packed in *.kpp , it will not break retro-compatibility to remove them.
That's fine with me.
Can you coordinate the final pattern selection with animtim? He did the current set, to a large extent.