Page MenuHome

Sculpt/Paint: Dynamic Stroke Spacing
Needs ReviewPublic

Authored by Pablo Dobarro (pablodp606) on Aug 8 2020, 1:57 PM.
Tags
None
Tokens
"100" token, awarded by vejn."Like" token, awarded by IPv6."Love" token, awarded by kouza."Love" token, awarded by gilberto_rodrigues."Love" token, awarded by Anubis."Like" token, awarded by hitrpr."Love" token, awarded by Loner."100" token, awarded by Frozen_Death_Knight."Love" token, awarded by valera."Love" token, awarded by monio."Mountain of Wealth" token, awarded by Brandon777."Love" token, awarded by 14AUDDIN."Love" token, awarded by andruxa696.

Details

Summary

The Space stroke type creates brush steps at a fixed distance. This means
that when the stroke is fast, it has to create a large number of steps
to fill the distance between two input events. If all these steps can't
be computed in real time before the next event, the stroke starts
lagging.

Dynamic spacing limits the number of steps that can be created between
two input events. When more steps are necessary than the specified
maximum, a new spacing is calculated to distribute the maximum number of
steps between the two events. This means:

  • Fast strokes won't lag as long as the maximum number of steps can be computed between two events. Performances is much more predictable and stable.
  • Spacing can be reduced drastically for most brush presets as dynamic spacing takes care of reducing the steps count on fast stroke. This means that slow and precise strokes will be much more responsive and defined.
  • Default brush presets needs to be tweaked to support dynamic spacing with an optimal behavior. This will be done in later patches.

Fixed Spacing, current default:

New default with dynamic spacing:

Diff Detail

Repository
rB Blender
Branch
arcpatch-D8508_1 (branched from master)
Build Status
Buildable 9875
Build 9875: arc lint + arc unit

Event Timeline

Pablo Dobarro (pablodp606) requested review of this revision.Aug 8 2020, 1:57 PM
Pablo Dobarro (pablodp606) created this revision.
Sergey Sharybin (sergey) requested changes to this revision.Aug 10 2020, 11:21 AM

The biggest concern here basically goes as that we should not make brush behavior to depend on how powerful the computer is, and how complex the mesh is.
The smaller concern is that there is now (proposed) yet another set of settings which controls how brush spacing works.

There must be a way to have predictable and controllable way to define brush setting which:

  • Does not require artist to tweak multiple parameters.
  • Work nice for all brush types.
  • Work nice for all brush radiuses.

Currently the stepping is limited by a percentage of radius, maybe this is not so good heuristic.

This revision now requires changes to proceed.Aug 10 2020, 11:21 AM

The biggest concern here basically goes as that we should not make brush behavior to depend on how powerful the computer is, and how complex the mesh is.
The smaller concern is that there is now (proposed) yet another set of settings which controls how brush spacing works.

There must be a way to have predictable and controllable way to define brush setting which:

  • Does not require artist to tweak multiple parameters.
  • Work nice for all brush types.
  • Work nice for all brush radiuses.

Currently the stepping is limited by a percentage of radius, maybe this is not so good heuristic.

Well I'm only one artist not all of them lol, but I think it's not a big deal. 95% of the time I would need adaptive spacing and when I will need constant spacing for some tasks (usually some pattern brushes) I will switch to fixed spacing.

From my expirience with 2D applications I can say next:
a) brush spacing smaller than 1-2 screen pixels is never useful, so there should be lower limit, that prevents heavy lags with wrong settings (too low stepping).
b) smoother brushes allow larger spacing, the same for weaker brushes (less total height — less steps)
c) dependence from max radius is okay: even if it produce steps, big brush usually means rough work or texture paint.
d) for fast strokes, where 2 input points are far from each other, positions of steps are on one line (without jittering) and rotation is same — may be there is some place for optimisation.
e) fastest brushes, AFAIK, in Paint tool SAI 2, and this application use all CPU cores for strokes and do not have chunks like Krita (or they are syncronized perfect).

@Vyacheslav (hitrpr) thanks for your feedback.

A small note, in the future try to avoid bringing up other software in the discussions. In this case is fine. But it often scales up to more people replying bringing screens and feature design from other applications which is not allowed.

In this case, the spacing should not depend on how powerful the computer is, but on the rate of the input events the operator uses (which may be a problem in some platforms). If the computer is not powerful enough the brush will lag, but it will lag in a predictable way.
There should be something to control the amount of computation that is done between redraws in order to keep the framerate consistent, which is the most important thing for these kind of tools.
I've already tried other solutions in the past (like D5676). I also tried something similar to this patch, but calculating the average time each brush steps take to start dropping steps if the total between to events is too different from the average, but it has problems with brushes with variable size and it didn't produced results as nice as this solution. This is by far the thing I tried that works the best.

I think D5676 is to be finished first. And if that is not enough we should find a way to lower number of steps per stroke without visually degrading quality of strokes too much.

@Dalai Felinto (dfelinto), yes, I heard, what Ton said about this. And will not break someone`s copyright. AFAIK Ideas and methods can not be copyrighted, only certain design and code.

In this case, the spacing should not depend on how powerful the computer is, but on the rate of the input events the operator uses (which may be a problem in some platforms). If the computer is not powerful enough the brush will lag, but it will lag in a predictable way.

From T80608: Sculpt Mode Stroke Perfomance I understand you still want to go ahead with this patch.

But what this patch seems to do is make the spacing depend on how powerful the computer is. Are you saying that is not what it does? Or that you want to implement this patch in a different way? Or is the above comment outdated, and you do think it's ok to have the stroke depend on how powerful the computer is?

Further, I don't think making the spacing depend on the rate of input events make sense either. Some tablet/OS combo might be able to get an event every 1ms, and another 10ms, ... why should this affect the spacing?

@Brecht Van Lommel (brecht) For brushes like Draw Sharp or Pinch where the effect is created by a series of small dots, the lower the spacing is, the most precise the effect of the brush look. With this patch, it is possible to make the spacing work like "If the new event is further than 1% of the radius (or even lower), add a sample. If the stroke is moving too fast that needs more than N samples to fill the gap between to events, just create N samples with even spacing". As long as you don't exceed the number of samples that can be created between two events with the speed of the stroke, this should be the same thing as regular spacing. We can also lower the spacing of those brushes without this patch, and as you don't draw the stroke too fast it is going to work, this is just preventing the lag in those situations.

If I'm understanding this correctly, this makes the spacing depend on the input rate and not on how powerful the computer is. The dots spacing method is the one that depends on performance as it just adds a sample per new event. This one guarantees that for a particular event, at least N number of samples are going to be created, even if it lags, and that all steps are going to be created with a minimum spacing.

What is true is that the maximum number of allowed samples is will probably need adjustments depending on the hardware and the pen tablet event rate. The higher it is, the better, as long as the computer can handle it without lagging.

I have the same problem in grease pencil when drawing very fast. After debugging, we saw that the number of events received was not enough, especially on windows.

The solution that I implemented in grease pencil was to calculate the intermediate points between the two events using an arc that joins both points. To calculate the angle, the vectors that form the vertex between the prolongation of the previous point and the vector of the current point are used.

We were testing a patch to receive high frequency events in Windows, but in the end it was discarded because the UI was affected and in some stablets it did not work.

Forget about events and input rate for a moment, they are an implementation detail and irrelevant in describing the desired behavior.

What matters is that when you paint, you make a certain pen motion that results in a certain trajectory. And every point along that trajectory has an associated time. The more events provided by the OS, the more accurate we can reconstruct that trajectory. The number of events is highly dependent on the OS and tablet hardware, and not a reliable indicator of how fast the physical pen moves.

With that in mind, the current default behavior can be described as:
a) Brush steps are always at evenly spaced distances to keep a consistent stroke quality

And with this patch the intended behavior seems to be either of these or a mix of both:
b) Brush steps spaced at distances depending on the physical pen motion speed, reducing stroke quality as the pen moves faster
c) Brush steps spaced at distances so that stroke does not lag behind, reducing stroke quality when the computer is slower or the mesh has more polygons

@Sergey Sharybin (sergey) and I think that both b) and c) are bad and not something that other apps need to resort to, and that we should look at other solutions to performance problems.

Finishing the stroke queue I think is the first step, and then from there look at improving performance without lowering quality, and maybe increasing the default spacing for brushes where there is little visual difference with higher spacing.

I have the same problem in grease pencil when drawing very fast. After debugging, we saw that the number of events received was not enough, especially on windows.

I think that's a different problem. For grease pencil the issue was not enough events and resulting brush steps to get good quality, this patch is about using fewer brush steps to improve performance.