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
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?
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.
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.
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.
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 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.
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.