[Bf-committers] Bump: [bf-blender-Patches][31450] Fix Airbrush & Smooth Stroke Behavior - Onion #3

[Jason Wilkins]

I submitted this before the GSoC but there was no action, now that
GSoC is over I wonder if anybody is free to review this:
http://projects.blender.org/tracker/?func=detail&aid=31450&group_id=9&atid=127
http://codereview.appspot.com/6202077/

Thank you.


---------- Forwarded message ----------
From:  <bf-blender-patches at projects.blender.org>
Date: Sun, May 13, 2012 at 1:52 PM
Subject: [bf-blender-Patches][31450] Fix Airbrush & Smooth Stroke
Behavior - Onion #3
To: noreply at projects.blender.org


Patches item #31450, was changed at 2012-05-13 13:49 by Jason Wilkins
You can respond by visiting:
http://projects.blender.org/tracker/?func=detail&atid=127&aid=31450&group_id=9
Or by replying to this e-mail entering your response between the
following markers:
#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+
(enter your response here, only in plain text format)
#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+

Status: Open
Priority: 3
Submitted By: Jason Wilkins (jwilkins)
Assigned to: Nobody (None)
Summary: Fix Airbrush & Smooth Stroke Behavior - Onion #3
Category: None
Group: None
Resolution(Old, use status): None
Resolution: Open
Patch for:


Initial Comment:
Last summer I noticed two behaviors in paint strokes that I believed
were incorrect.

1. "airbrush" strokes painted on both timer and mouse events, so a
slow airbrush could be "sped up" by moving the mouse.

Although it may be somewhat intuitive to have a the rate of the
airbrush speed up if you "shake" the airbrush, I think that this is an
unintended feature.  If we want to add a "airbrush rate goes up if
mouse moves" feature, I think it should be done deliberately.

2. "smooth stroke" would set its initial mouse position based on the
first successful "hit" on the pbvh raycast instead of the first place
the mouse is pressed.

This means that you could not properly start a smooth stroke that does
not start out hitting the object surface, however paint strokes are
purely 2D operations and should not depend on anything being hit in
3D, so the 2D stroke should be smooth and when the smoothed point
finally arrives over the object's surface the stroke should start.

The modification of "test_start" to take the smoothed mouse coordinate
also sets us up to be able to handle snapped coordinates later

--

I removed the "paint_stroke_space_enabled" external function because
it clashed with the internal "is_space_enabled".  The only use for
this function was an XXX issue that needs to be addressed separately.

Another fix is to force drawing for every event, you can also see
where the smooth cursor is while the mouse is not over the object.
Before there was a general problem where the cursor would not be
updated unless you caused a change that resulted in a need to redraw
the object.

Finally, although last_mouse_position is not used by the
sculpt_update_step function, it was being incorrectly updated to be
the same as the current mouse position. This would have been a problem
if something in sculpt actually used it.  However, it looks like
sculpt just duplicates some of the work of saving the last mouse
coordinate.

As with the other Onion patches, this one anticipates some future
changes.  The "one_time_init" function and the "stroke predicates" as
well as the "input_ok" variable are all artifacts from the future that
were convenient to go ahead an integrate.



----------------------------------------------------------------------

>Comment By: Jason Wilkins (jwilkins)
Date: 2012-05-13 13:52

Message:
http://codereview.appspot.com/6202077/

----------------------------------------------------------------------

You can respond by visiting:
http://projects.blender.org/tracker/?func=detail&atid=127&aid=31450&group_id=9