GNOME Bugzilla – Bug 741199
Brushpipe angle is calculated wrong
Last modified: 2018-05-24 14:56:33 UTC
If a angular brush pipe is created, the angle of painting is wrong. gimpbrushpipe::gimp_brush_pipe_select_brush This affects master, too.
Wrong how? There is a known issue that the pipe angle is on top whaterver dynamics sets so are you sure you are tesing with in-gimp dynamics OFF?
Created attachment 292244 [details] [review] gimpbrushpipe-angle-hack.patch Yes, with dynamics-off. I made what you would call an "ugly hack" to see the difference.
So... what you are doing is taking direction from between last stamping position and current postion and not from the direction from between last two events. Correct? Inacuraccy of direction is not only pipe brushes problem. The idea is pretty good tho and should probably be implemented in the brush core, in interpolate function.
yes, correct.
Created attachment 294456 [details] [review] 0020-fix-gimpbrushpipe-angle-1.patch In my opinion, the calculation should stay in the brush pipe, because it is only calculated, if the next brush is selected. This is mostly not as often as in brush core, where the calculation of direction would be useless until a brush pipe is selected. So there it saves time. Furthermore i added some functionality. There was a problem with brush pipes and dynamics. The correct brush of the pipe was selected but the angle of the dynamics were added, so the brush was painted wrongly. With the patch, I identify the brushes of an angular brush pipe as members of a pipe and omit the dynamics angle, letting the brush pipe select the correct brush.
Comment on attachment 294456 [details] [review] 0020-fix-gimpbrushpipe-angle-1.patch Isn't that member "is_pipe" exactly the same as GIMP_IS_BRUSH_PIPE (brush_core->main_brush)?
Created attachment 310707 [details] [review] 0020-fix-gimpbrushpipe-angle.patch Not exactly, but indeed, that value can be used and simplyfies the patch enormously.
I just applied the patch an I'm not sure if it's the right thing to do. What's wrong about being able to modify the result of a brush pipe angle calculation? The only effect I see is that instead of painting an angular pipe in stroke direction, we paint it rotated by the set angle. That's rather a feature than a bug, but I'm not sure :)
There is nothing wrong with it. But there are two methods for setting an angle. First, the brushes in the pipe. Second, the direction set by the dynamics. If both are active, the angles are added, and that is wrong. Only one angle should be used.
Does the more recent patch obsolete the hack?
Comment 3 is about this being an issue for all brushes. Comment 8 is about whether the current behavior is a feature. Can we try to figure if we want this for 2.10?
Sincerely I think that a .vbr or a .gbr brush with a paint dynamics to control the angular behavior is more efficient than to build gih brushes with angular parameter. I see, Angular on .gih matrix as another discrete alternative, for instance, to something as an 'angular incremental' ;-), in the sense, that is possible to use it to build gih brushes where depending of angle the gih sends to gimp a specific mark (O°, 90°, 180°, 270°, if my matrix has 4 ranks to this parameter). The unique thing that I have noted using a .gbr with a simple dynamic matrix (Angle x Direction)... the behavior of the first stamps are a bit imprecise... the brush doesn't know which position must be placed the stamps, see my attachment (.png and brush to test this behavior).
Created attachment 345904 [details] Effect first stamps of a .gbr with an Angle-x-Direction dynamic
Created attachment 345905 [details] Simple .gbr brush to test Angle x Direction Paint Dynamics
We handle the imprecision in another bug already. Please note that the scope of this report right here was pretty focused - if I got it right, the point is whether any angle set is applied in addition to brush pipe angle calculation, or not.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/631.