I’m so happy you decided to implement all of those options, it is so cool and the texture will be even more awesome 
1 Like
No problem, texturing was one of my many little annoyances about how things work in Krita. Now that I’m somewhat familiar with the code (I feel like it will take a lifetime to completely understand it), I might as well start fixing some of those things!
1 Like
Fantastic !
One last thing and the tool is complete: rotation of textures? (gasp!)
Haha, yeah, I suppose that would be pretty useful… That would go along with the other thing I want with textures, which is easy re-sizing. Rotation will be a lot harder, both in implementation and UX, because not only do I have to figure out how to rotate the texture, but also how to show what the current rotation looks like. Resizing is already built in, I just want the ability to put the resizing on the top toolbar, where brush size/flow/opacity sliders can go.
I think the way to go for rotation is to make it work with rotating the canvas. Currently, when you rotate the canvas, the texture rotates with it, even though the brush doesn’t. Ideally, the texture would not rotate with the canvas, then when you want to draw the texture at a different angle, you can just rotate the canvas, making it very clear how the texture will be applied. Hopefully that will also be an easier way to implement it, too.
That will probably take me a while to get to, though. Hopefully someone more familiar with how the canvas rotation and texture application works can get to it before me… 
2 Likes
Attempting to implement these features in the smudge brush engine may be even more difficult. I spoke with one of the main developers and he said the smudge brush engine has the most complicated code out of all the brush engines. The final results for implementing these features in the smudge brush engine might be worth the extra work, but noticeable brush lag might occur on lower end computers.
Hi, @Voronwe13!
Is your feature ready for merging into master? At least, is it “feature-complete”? If so, please make a merge request and I will make testing packages so people could test it.
Hi, @Voronwe13!
About texture rotation: please keep texture rotation task separate from your main task. It is rather tough to implement from performance point of view. You would have to pre-rotate the texture (or a part of it?) in a wrapping way and then apply that in the stroke itself. You cannot do the texture rotation on-the-fly, because it will be extremely slow.
PS:
Just to make it clear: I don’t mean “don’t implement texture rotation”, I mean “keep texture rotation as a separate patch/merge request”. Rotation patch may cause a delay and I want your main patch to be merged in time for 4.3 release (merge window closes on the 1st of May).
1 Like
@dkazakov I’ll try to have the merge request for the Value and Lightness modes for texturing put in tomorrow, and hopefully for gradient mode by the end of the week. I’ll look at texture rotation and what it will take to do that, but yeah, that will definitely be a separate patch.
1 Like
Just for motivating the people.Your work is great and this is only scratching the surface.Testing how to paint with this kind of brushes. @TheFlow I have retouched a bit your brushes to fit my own taste.
9 Likes
woah! 
1 Like
I can’t show more because this is a commision. But you can see interesting effects in the skin. I will try to convince the customer to publish the final result because i love it.
8 Likes
@dkazakov Well, I was going to submit a merge request with the new texture features, but the new resource management code that was added recently completely broke Krita for me, to the point where it doesn’t run at all. Since it’s really new, I would rather let whoever was working on that fix it, before I try to pull the latest master and make my changes to that. I’ve already submitted a bug report: https://bugs.kde.org/show_bug.cgi?id=420009
I can keep working on this using the old version of the code, but I may put Krita on a back burner for a while until this is fixed.
Hi, @Voronwe13!
Please submit the patch against the version that works for you, preferably ‘krita/4.3’ branch. And I will port the code to master for you
2 Likes
Hi, all!
Here is a testing package for Windows with @Voronwe13’s work : https://yadi.sk/d/E1BgAe3-tOfQTg
Hi, @Voronwe13!
I have a few worries about the patch, and I’m not sure whether we should think about/fix them…
-
Brightness/Contrast options in the texture option work a bit differently from the brush tip area. Is it a problem? Or, more precisely, is it a problem we should try to fix?
-
There is no “Neutral value” slider. Original textures engine didn’t need that (because it didn’t have neutral point at all). Should we add it?
-
Do we actually need two different options for “Value” and “Lightness”? Can we keep only one of them? Or there is any usecase when both are needed?
-
I don’t think it’s a problem. Brightness and contrast still basically work how I would expect them to work.
-
I’m not sure textures need a neutral value slider. It doesn’t really apply to the Value option, since the full color is where it is white, instead of the neutral point. I’m not sure how much demand there is for the Lightness option, where this would be relevant, and how many existing textures would need their neutral point adjusted to look correct.
If it’s not used much, and existing textures already have the neutral point at 50% gray, then it can just be documented that anyone wanting to make new textures for the Lightness option should design the texture with 50% gray as the color portion.
The neutral point option makes more sense for the brush tip, because there people will be making stamps from existing color images that might not have the neutral point set correctly. I’m not sure this is the case with textures. Would be a good question for artists, though.
I will try adjusting the neutral point on some of the existing textures, to see if they give better results with the Lightness option. If that’s the case, then maybe it should be added (but only enabled if Lightness is chosen).
- I think both are needed.
Value is useful for most of the existing textures, since they are designed for either white or black to be the color, and that’s what the value version does. It only differs from the original texturing in that instead of the texture going from color to alpha, it goes from color to black. (Also, white is the color instead of black, because that’s how the textures are designed… most of the existing texture brushes have to invert the texture, so for testing Value/Lightness you would generally want to turn off the invert option).
Lightness is useful for some of the existing textures, and future textures, because it allows highlights in addition to shadows in a texture. Like I said above, I’ll test adjusting some of the textures to see if I can make them show off this capability better. An example would be adjusting the reptile texture so that the scales look wet (have white highlights).
In fact, now that I think about it, I should probably have two versions of the Value option: the existing one, where the texture maps directly to the value, and one that maps inverted, so that black is full color, and white is white. I would probably call it Value-shadows and Value-highlights. I’ll test that out too.
Theoretically, if I get it to use the gradient to define the map, and gradients could be created with Foreground color and/or Background color as points on the gradient, we could condense all of the modes to that, and just have the user select a gradient. Currently the gradient tool only allows pre-specified colors for new gradients. The existing Foreground/Background Color gradient is a special gradient that is hardcoded in.
Here’s an image where I used the same color with the reptile brush. First is Value mode. Second is Lightness mode. Third is lightness, but I used the “Color adjustment curves” filter on the texture to bring the neutral value down, but still make the highlights pop and keep the shadows looking somewhat natural. I would be curious if a neutral point adjustment would get the same effect, or if the textures just need to be adjusted by hand to look right.
2 posts were split to a new topic: Feature request: to use two or more colors at the same time at the same brush tip
Well, it would mean that people will have to make an additional adjustments step when preparing textures. Which is not very good.
I have a feeling that this complication may “frighten” the artists away from using this feature.
Can’t we just invert the texture to achieve this effect?
Btw, how do you think, do we need “cutoff” options for the new modes? I don’t really understand how they work now. Perhaps, they should be hidden?
Don’t get me wrong, I don’t mind additional control, so a neutral point slider wouldn’t be a bad thing. Like I said before, I would be curious to try it and see if it actually achieves good results with the existing textures in Krita. I just have a feeling that textures will have to be designed with this use in mind, and if they’re already designing them for it, having guidelines already documented for how to design a texture for this capability would be good, and might alleviate the need for the slider in the first place. But there’s certainly no harm in having it.
I don’t think artists frighten that easily 
, especially those who were already adventurous enough to try making their own brushes. When it appears in a release version, I can update the manual for these options to make them easy to understand.
Unfortunately, no. Inverting the texture just changes which part of the texture maps to black/shadows and which to color. No matter what, it still only does shadows. My idea would be to have an additional mode that maps instead from color to white/highlights.
They do seem to have weird effects with these options, so it might make sense to gray them out. That being said, some artists might want those effects anyway, and I don’t think it breaks anything to leave them enabled, so I would probably just leave them be. I can just make a note of the issue in the documentation.