Talk:Brainstorming/BrushEngine

From MyPaint

[edit] Comments to Acyclic graph for input/output mapping

More Pros:

• Allows us (mathematically) to do more interesting mappings than currently possible
• Might make it more natural to combine several inputs together and use the result for many settings

More Cons:

• Brush editor GUI will get more complex (graph instead of list) and need a complete rewrite
• Some of the finer details in the brush engine that have matured a bit now will need rewriting
• Advanced brushes will require more planning and disqualify users who just move sliders and see what happens
• It will not automatically solve the challenge to make the options both powerful and easy to understand

Let us take the example of Speed1/Speed2. I assume you want to get rid of them and have only one Speed, correct? If so, then this would be the unfiltered, raw speed. I hope you understand why we /never/ want to use the unfiltered speed for anything. So, every brush that uses the speed input will run it through a "filter" node first. I assume this "filter" node would have a "filter strength" input (which will usually be constant, but may also be driven by another input). I can't imagine that this will make things any simpler, or make brushes any easier to explain to persons without a mathematical background. Currently we have sane default values for the two speed filters - with the new system, when adding a speed dependency to a brush that doesn't already have it, you will need to guess a good default value for the filter first. (A GUI mockup would be helpful!) --maxy 19:08, 30 January 2010 (UTC)

I agree, a mockup would be helpful, and I will try to provide one as soon as possible. Basically what I had in mind is an interface similar to the one of Conduit, only with a bit more complex graphs. AFAIK Conduit uses some python library to manage those graphs. As for clarity: some people will of course never get it. It is the same with complex graphical postprocessing in Blender. But I think that all the people that know how to do brushes now would get it. And it would be easier to translate (because only simple filters would have to be explained and not how every single mapping works. Regarding speed: yes, this is exactly what I had in mind. It would also make it possible to attach new filters easily. And add inputs like tilt without much hassle. Also we would be able to add devices like SpaceNavigator as inputs easily. --Lukacu 20:06, 30 January 2010 (UTC)

One more thing: the change does not have to be fast. We can start by making brushlib more flexible. Then we can write a python translator that would transform the old format into a new one (as far as I know the current format is a subset of what I am trying to achieve. After that we add the new format and after that we create the GUI components. This way old brushes could be transformed automatically. --Lukacu 21:26, 30 January 2010 (UTC)

Hm... I guess there is another point I should add. Basically, you propose to rewrite the brush engine from scratch that I have built up during the last 5 years. And I'm actually happy with how it is currently :-) What you propose to do is quite a bit of work, especially if you also want to keep old brushes working. If you insist doing this, be aware that I might only bother to look at your code when everything is really working splendid and ready to be integrated. I'm pretty much flooded with other stuff that I think is more important. (Advice: try to make smaller proposals with more immediate benefit.) --maxy 20:44, 1 February 2010 (UTC)

I am not saying that we should write it from scratch, but yes, I it is a major refactoring job. It is also primarily an idea, but I think that we will sooner or later have to consider it more seriously. Because the current design has it's limitations and just adding new parameters will make the entire thing even less intuitive that it already is. Of course some kind of compromise way is also possible ... i just do not know what would that be at the moment. --Lukacu 12:22, 2 February 2010 (UTC)

[edit] New input value: direction change

"Create a direction change input value that is zero in straight stroke segments and increases when the direction changes, up to 1 for 180 degree turns."

Sounds interesting, but how do you calculate this input value? This just got me started with playing around in the brushengine again :) I had an idea (but it didn't quite work IMO), have a look at this commit in my brushstorm branch. If nothing else, it should give you an idea how to add a new input.

Also, no matter what you do, elliptical dabs will stay elliptical and not bend along a sharp edge. And the brush engine can't know the future direction when it paints dab in the middle of an edge - so if you need this you need to add delay. Hm, there might be some better ways to achieve what you want... --maxy 20:44, 1 February 2010 (UTC)

First off, I have no idea how the brush engine works internally, so whether this would work as it stands or not I don't know.

You'd basically take the current stroke direction and compare it to a past value X, against an average of all directions between X and now, or a combination thereof. For example, if the current stroke direction is 80 and it was 35 at X, then the direction change value might be (80-35) / 180 = 0.25

Actually, I don't want the dabs to bend (even if that would be the optimal solution) in this case. Just to shorten for moderately sharp curves and revert to circles for extremely sharp ones. There might indeed be better ways, but this seems (brush engine ignorance speaking) the easiest way to do it in the short term. --Artis 01:03, 10 February 2010 (UTC)

Think of it like this:

--Artis 02:09, 10 February 2010 (UTC)