[proof-of-concept] Scriptable Brush

Explanation

This is a quick experiment that I did for fun. It demonstrates a way of making scripptable brushes via Lua.

In the video I played with drawing speed and drawing angle. I’d really wanted to use pressure, but I don’t have my tablet with my dev environement :frowning:

I chose Lua because it’s simpler to embed in C/C++.

I hacked the pixel engine by adding a new “dynamic sensor”, which exposes other sensor values and run a lua script to calculate its own value.

Related Topics

Discussions

This demo could be relevant to node-based editors. If we fix the input as all existing sensors (pressure, speed etc.), and the output as the control options (size, opacity…), I think it should be possible to build such an editor. The nodes will be some math connecting these values. The Lua script in my demo is actually the same thing, just in a different format.

On the other hand, my approach is very limited compared with a full-fledge node editor, which would be way more difficult to implement as @halla’s pointed it out. Potentially this version could be a medium-small project that can support lots of use cases.

Lastly, performance may or may not be an issue, I did not test it thoroughly. My guess is it’d be OK if we just use simple math in Lua. Maybe LuaJit can help?

21 Likes

This seems awesome. Krita supports python scripting too, can python be similarly plugged in? Also do you plan to upstream this, there may be need to fine tune it and figure out the UX if necessary.

1 Like

Hi Raghavendra, for short-term I don’t plan to upstream it yet. I may or may not be able to do it in a month or so.

For now I’d like to help push the idea, collect feedback and form a design, e.g:

  • Is it useful or not?
  • Technical details (e.g. lua and/or python)
  • Future plans (e.g. node editor)

About Lua and Python, I chose Lua for now because:

  • I vaguely remember the performance is like pypy ~= luajit > lua > cpython
  • The Lua C API seems simpler than the Python C++ API.

But this is yet to be discussed with Krita experts. There could be other considerations as well, e.g. which language is better for brush makers. I could start a new thread if the feature seems useful.

2 Likes

This is nifty! I think I see why Halla said a node-based brush system would need an engine all its own, though - You’d want to be able to e.g. change the order of compositing operations so it would go well beyond “just” a custom sensor like you have here. Still, really cool idea and I’d love to get to try it out.

2 Likes

Thanks. I agree with you and I updated my post.

The idea looks awesome!
Not sure how it works but with a entry that exposes all the options and variables would allow greater control on the behaviour than using tiny graphs on different entries and make driver variables possible.

I’ve been trying to build an Appimage, but it’s been tough :sweat_smile: (linuxdeployqt does not work in Arch Linux, invent.kde.org was down…)

But it’s running now, hopefully I will get something soon.

1 Like

OK, an Appimage is availble here:

4 Likes

This is interesting, its something that firealpaca/medibang also have and they also use lua. I think this can open up some interesting possibilities

2 Likes

I definitely like the sound of this! It was fun to play around with in BlackInk. To fit in with the motif of Krita, I do think Python would be a more apt language for it but that’s just my opinion.

1 Like

This would be pretty great for some use cases I have

If this would work with any brush engine.

1 Like

I guess so, althougth I did not check the code of other engines.

Which engines are you thinking of?

Mostly the Smudge engine in my case.

Interestingly, I realized that it also works for smudge engine (and possibly others) in my appimage. So maybe you can give a try.

I’m only seeing this now and it’s great.

I think python is better.
As far as I know python is very easy to learn which is a big advantage.
Besides krita itself, like blender or other authoring programs also use python, I think using python is easier for creators to use.
In addition, the ecology of python itself is much better, maybe you can use the existing things in python to help make brushes.

Nodes are important, even though python is easy to learn, it is still not as simple as graphical nodes.