Krita has been wonderful for me in the year and a half or so I’ve been using it semi-professionally, but one of the issues I have with the software is the Brush Editor.
Even though I’ve made a few brushes myself, and modified other people’s for my needs, it’s hard to get a good idea about how a brush works at a glance and it’s hard to know where to start when I have an idea for a new brush in mind.
I think that offering a node-based editor for brush designing and editing would not only be useful, but also be an cool development in digital art.
Overview
- Background
- what’s wrong with the existing brush editor?
- what’s good about the existing brush editor?
- what is a node-based editor?
- why might a node-based editor be a suitable brush editor?
- Initial concept
- concept mockups
- exposing a node editor library for plugins (with existing examples)
- Accessibility
1. Background
What’s wrong with the existing brush editor?
My main issue with the current brush editor is that it’s a verbose interface that’s more an options menu than something I feel confident building tools with.
The current brush editor is a verbose interface with a lot of space dedicated to checkboxes, curves, dials, etc. that is noisy to parse if you’re not already very experienced with it. It’s useful in that it exposes all values that can be given to a brush and its verbosity lends itself to poking and prodding, but reading the brush’s behaviour at a glance and being confident in where to start on creating a new brush doesn’t come naturally to this form of brush editor.
What’s good about the existing brush editor?
The scratchpad provides a good testing ground, and I am not proposing an overhaul of the way brushes work (mainly because that would sink this proposal and be clearly too far out of scope). While I do think that a node-based brush editor might expose possibilities of more user-definable inputs to brushes in future, I feel that including that within an initial pre-proposal is premature.
What is a node-based editor?
A node-based editor (or “graph editor”, there’s not really a standardised name?) is a method of building behaviour in directed graphs. Each “node” is a card with annotations about inputs, outputs, and what it does with those inputs and outputs that can be dragged around a workspace and connected to other nodes. Nodes are connected output-to-input to “sockets” that correspond to the compatible data types (i.e. numbers, textures, position etc.) in a way that lets the user design and compose fairly complex behaviour.
Node-based editors have become popular in game engines and 3D software such as Blender (which even has an internal initiative to make as many components of the software able to be done via nodes) and Unity. Blender and Unity have node-based shader & scripting editors, and Blender has procedural geometry via node-based geometry editors in the works in an upcoming version.
What makes a node-based editor a suitable brush editor?
- Easier to “read” brushes
As an artist I like to have an idea of what my tools do, this means I need to dig into the editor interface anyway. Opening a node-developed brush in an editor can show me how the whole thing works fairly easily, with me just needing to pan about the scene to see what’s going on if it can’t all fit on screen, and an output node always being the place to start looking for what’s going on.
- Easier to make brushes
When I’m making or modifying brushes it can feel like I don’t know where to start or I’m unsure if the behaviour I want is even doable in the current brush engine and it’s difficult to experiment with different settings and still have a good idea of what’s going on. I’m sure you can learn the ins and outs of the editor in its current form but I don’t feel like it’s built for experimentation and planning.
- Paths of feature extensibility
A node-based editor also opens up potential for more complex brushes in the future, if such things were able to be supported. This is more a footnote, I am aware of the amount of work that would have to i.e. go into letting us have scripted drivers for values like Blender’s shaders do, but there’s brush features with less of an overhead that I feel a node-based editor would help open up possibility for.
2. Initial concept
Note that I’m not proposing anything here 1. uses the mockup style I’ve used 2. must exist, this is just me putting forward some ideas and using a unified style to make them all look coherent. An editor would have to account for i.e. themes and such.
Concept mockups
This mockup shows:
1) An output node suited to a specific brush engine
2) Input data nodes (i.e. tilt, pressure, time)
3) Texture nodes
4) Socket compatibility (red to red, grey to grey)
5) Transforms on data (i.e. the curve transforms in the existing editor)
6) Basics of an interface for adding additional / changing nodes via a menu bar etc.
I’ve also sketched some other nodes, knowing these are only variable degrees of possible.
a) A shortform of plugging i.e. pressure directly into a curve transform.
b) Combining data, in a similar way to the way data is combined to effect brushes currently, but considering each one with a different weight.
c) Data constants, for i.e. a fixed rotation.
d) Feature switch, for determining how a brush works based on features supported by an input device (i.e. a graphics tablet, I know my old bamboo doesn’t support tilt but by cintiq does). I don’t know if Krita has the ability to poll for input device features so I expect this to not be possible without having access to a database of input device features but I think the concept is worth bringing up.
I don’t think these are necessities but instead just an exploration of how brush design might work and what different means of data input might look like.
Exposing a node editor API
One of the things that software such as Blender or Godot does is expose the tools for people to develop their own node-based editors for plugins and the like.
This involves extra work as opposed to directly writing a the node editor system for the brush editor alone, but it would also separate maintenance between the API itself and the brush editor. The Blender Foundation has a working group among its contributors that want to make as many things drivable by node editors as possible, I don’t think the same needs to apply to krita but giving this tool to plugin devs could lead to a bunch more behaviour being user-automated or easier to express.
Existing examples of general node editor APIs are:
3. Accessibility
There’s some accessibility considerations for node-based editors, namely you need to be able to visually parse them and if they work with in the QGraphicsItem class then that’s gonna be invisible to say, a screen reader. I want to know if there’s people who rely on the current layout for accessibility reasons, and if there’s a way to account for that in a possible way of implementing this.
Another thing to consider is the problems with using colours as socket type signifiers, this could be replaced with i.e. sockets that have a monochromatic icon signifying their type so that colourblind users would be able to use this system (I know of a few colourblind artists).
Anyway, that’s the work I’ve put into thinking about this concept. I’m interested in what other people think about this kind of thing? By no means do I want to dictate this kind of thing, nor do I want to get mad if this is something that’s just not possible given workloads etc. I just think it’ll be something cool, but I would be surprised if this gained traction, it’s a really hefty project in terms of the work that would be to be done and I don’t know the ins and outs of the krita brush engine infrastructure.
)
) can give us a better opinion about this because they’ll probably be the first impacted by this if it’s on day implemented…
