How big of a project would making a new brush engine be?

Develop Developer Questions
1

I’m currently trying to switch from a custom built minimalist painting software to Krita and my established workflow seems incompatible with Krita’s existing brush engines. I wrote that other software myself, but I lack experience with open source development and Krita’s development environment. So for now, I’m looking for some help to figure out the scope of a custom brush engine implementation, before I set out to learn all that software and coding style.

Conceptually, the indented brush engine works like a pallet knife with 0 thicknes and sharp edges. This allows me to fill in wedges of varying angles without interruption, which is essential for the way I paint fur:

image
image363×341 29.2 KB

Workflow wise, the technique is very similar to using the Freehand Selection Tool to draw a contour line line a color being filled in for a given distance to one side of that line. In more technical terms, every painting step uses the new and old tuple (pen position, pen angle, pen pressure, width, color). From the pen position, the pen angle is converted to an unit and multiplied by half the with. Adding and substracting to those scaled vectors, from the pen positions, then gives four point coordinates (two for the new and two for the old tuple). 4 points for a quad to be filled in with the color, while using pressure for blending. And some extra work to anti alias the outside edges and edges for direction reversals.

In general, it’s a pretty simple implementation, but it’s very different from how Krita’s brush engines work. And I’m also unfamiliar how much else the brush engine does, aside of defining areas to apply color values to. That’s why I wanted to hear from others, who are more experienced with the codebase, whether I’d be trying turn Krita into something it’s fundamentally not designed to do.

1 Like
2

:slight_smile: Hello @Zyonji, and welcome to the forum!

In principle your brush engine itself already exists, at least that is how I interpret your description because your app uses it, it must exist, now it is about how hard it would be to adapt your code to making it able to “plug in” in Krita’s brush engine system.
But since I am no coder, I’ll ping those who should know more about this: @tiar, @dkazakov, @wolthera, @Drawpile, can you perhaps help our new user with their question?
Thank you!

Now we have to wait for an answer of them, because at least one of them will know, I’m believe.

Michelist

3

Hi, @Zyonji!

You could check these two brush implementations as an example:

From your description, it seems like you brush looks more like the “shape brush”, though I’m not very sure.

1 Like
4

It’s a bit hard to really answer the question from a vague description. Generally, the hard part of implementing a brush engine is the brush behavior itself, integrating it is rather mechanical. To say more, I’d have to see the code.

5

That’s a useful starting point, thank you very much! At a glance, it doesn’t look too complex, though I’ll set aside time to read through it more deliberately.

The “Shapes Fill” brush is very similar to the workflow I described, so I may have done a bad job describing what I was looking for. Maybe this picture of example brush strokes would help? But honestly, a problem so narrow to my own preferences, that I don’t want to cause others work with it. I’m with the pointers you’ve given me!

image
image232×261 10.4 KB

1 Like
6

My implementation looks roughly like this. I cut it down to just the relevant parts.

internal void
RenderBrushStroke(open_gl *OpenGL, canvas_state Canvas, pen_target OldPen, pen_target NewPen)
{
  v2 OldP = OldPen.P;
  v2 NewP = NewPen.P;
  v2 OldV = {sinf(OldPen.Radians), cosf(OldPen.Radians)};
  OldV *= (0.5f * OldPen.Width);
  v2 NewV = {sinf(NewPen.Radians), cosf(NewPen.Radians)};
  NewV *= (0.5f * NewPen.Width);
  v4 OldColor = OldPen.Color;
  v4 NewColor = NewPen.Color;
  OldColor.a *= OldPen.Pressure;
  NewColor.a *= NewPen.Pressure;

  common_vertex Vertices[] =
  {
    {{NewP.x+NewV.x, NewP.y+NewV.y, 0, 1}, NewColor},
    {{OldP.x+OldV.x, OldP.y+OldV.y, 0, 1}, OldColor},
    {{NewP.x-NewV.x, NewP.y-NewV.y, 0, 1}, NewColor},
    {{OldP.x-OldV.x, OldP.y-OldV.y, 0, 1}, OldColor},
  };
  
  glBindFramebuffer(GL_DRAW_FRAMEBUFFER, OpenGL->CanvasFramebuffer.FramebufferHandle);
  glBufferSubData(GL_ARRAY_BUFFER, 0, sizeof(Vertices), Vertices);
  glEnable(GL_BLEND);
  glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
  OpenGLProgramBegin(&OpenGL->BrushModeProgram);
  glDrawArrays(GL_TRIANGLE_STRIP, 0, (sizeof(Vertices)/sizeof(*Vertices)));
  OpenGLProgramEnd(&OpenGL->BrushModeProgram);
}

The shader code in this case would just forward the color value without further processing. Before that function, I’m just processing the WinTab data in a message loop and map those integer values to float values in the canvas space. For example mapping the pressure integer to a float ranging from 0 to 1. Nothing special really. I just wasn’t able to reproduce the behavior with any of the Krita brush engines.

Apologies for not being clearer in my description earlier. My first time interacting with a forum open source software like this.

7

Yeah that shouldn’t be that big a deal to implement. Like most drawing programs, Krita doesn’t just pipe the raw device input into the renderer, there’s some input processing, smoothing and queuing going on before it gets painted. But this doesn’t look like it would be that big a project, you’ll “just” have to write a software rasterizer for it and the rest is a matter of wiring in the paintop.

2 Likes