[Bf-modeling] Proportional Edit Mode (Connected)

Tue Jun 18 10:51:58 CEST 2013

Hi everyone,

One thing I really miss when using proportional editing is colour coded vertices that show the falloff on the mesh itself. I have always found the selection area circle to be a little clumsy and hard to use well. Sure, we all make do, but I think that showing the selection on the vertices themselves is much more accurate, intuitive and user friendly. :)

Basically what this entails is that you colour the vertices based upon the strength of the selection area/falloff (based upon the falloff presets). Vertices that are most affected would be red, orange would be next through to yellow, green and blue as the selection strength/falloffs influence wanes blue would be no influence). This would allow people to see exactly which areas are going to be affected before they even move anything on the mesh itself as opposed to the current method which requires the user to transform geometry to see if it is exactly what they wanted or not.

http://img.photobucket.com/albums/v299/metalliandy/image_zps4dc0d92c.jpg

Cheers, 

-Andy

On 17 Jun 2013, at 20:28, Campbell Barton <ideasman42 at gmail.com> wrote:

> On Tue, Jun 18, 2013 at 12:02 AM, Howard Trickey
> <howard.trickey at gmail.com> wrote:
>> 
>> 
>> 
>> On Mon, Jun 17, 2013 at 8:52 AM, Campbell Barton <ideasman42 at gmail.com>
>> wrote:
>>> 
>>> Hi, There are cases where the current proportional edit-mode
>>> 'Connected' option doesn't give a nice smooth result across a grid for
>>> example.
>>> 
>>> For details see the 2 links below, but these images sum up the problem
>>> quite well:
>>> *
>>> http://projects.blender.org/tracker/download.php/9/498/35590/25506/ProportionalEditingBug.png
>>> 
>>> * http://i.imgur.com/U5TZW3i.png
>>> 
>>> 
>>> 
>>> Details... previous discussion and bug report:
>>> *
>>> http://projects.blender.org/tracker/index.php?func=detail&aid=35590&group_id=9&atid=498
>>> 
>>> * http://markmail.org/message/zkon53qzx32b5xek
>>> 
>>> 
>>> 
>>> Probably long discussion is not needed about this.
>>> 
>>> I think there are 2 obvious options....
>>> 
>>> 1) Accept that connected works like this, just close the bug and tell
>>> users it known limitation with current design.
>>> 
>>> 2) Add a second "Connected" option, so we have...
>>> * "Connected (Topology)" --- what we have now.
>>> * "Connected (Distance)" --- the real distance would work like it did
>>> many years ago, so only connected geometry is effected, but that
>>> geometry uses the distance between the 2 points without measuring
>>> along the topology.
>>> 
>>> {for a less obvious option}
>>> 
>>> 3) we could keep the options as they are now, but make "Connected"
>>> work without giving ugly artifacts,
>>> ... For example rather them simply measuring along edges we could
>>> measure across faces too... this would take longer to do and not
>>> necessarily give perfectly smooth results, but could still be worth
>>> looking into.
>> 
>> 
>> I think this 'across-face' rule could possible work.  After all, the
>> vertices
>> ARE connected via the face so it makes sense that the distance across
>> the face should be what is measured for the strength of the effect.
> 
> Added support for measuring across the face, r57528 (always enabled)
> 
> The falloff is still not nice and rounded, but with diagonals its a
> little better with a grid.
> 
> http://www.graphicall.org/ftp/ideasman42/pet_diagonal.png
> 
> I'm less worried about this artifact then before, I tested the Sintel
> model and I cant get it to show any artifacts using pet-connected so
> this is not so much a problem unless you are wanting to use pet on
> grids.
> 
> At least wont look like this anymore.
> http://i.imgur.com/U5TZW3i.png
> 
> 
> Bug [#35590], was in fact an unrelated error in the connectivity check
> (fixed r57532)
> http://projects.blender.org/tracker/download.php/9/498/35590/25506/ProportionalEditingBug.png
> 
> 
>> When I first read this, I though that it would destroy the use case in this
>> mail:
>> http://lists.blender.org/pipermail/bf-committers/2013-April/039799.html
>> -- that is, a long chain of vertices that form a path that comes
>> near itself distance-wise but not topologically, and you only want to
>> affect the ones that are near topologically. But here there are no faces
>> across which the vertices that are 'near distance-wise' are near across.
>> Even if you changed the long chain of vertices into a long strip of quads,
>> the same argument would hold.
>> 
>> I think what we would really like is that proportional edit measures
>> real distances that follow the surface of the mesh, as short as possible
>> following that rule.  If there are no faces, it would have to follow edges,
>> but measure the length along those edges.
>> 
>> But this might be hard to calculate, especially if the mesh is non-manifold.
>> There may be multiple paths between two points, complicating things even
>> further.
> 
> Was thinking over possible ways to get this working and concluded that
> its probably too much to calculate...
> we could...
> 
> - Add more fine grained measurement when walking over the mesh - use
> face centers, middle of edges, and walk across these too, the error
> will still exist but be less obvious.
> 
> - Record the path to the closest vertex, then re-walk the path and
> perform a `straighten` on that path based on surrounding faces.
> 
> - Fake it and take turning corners into account when walking over
> manifold edges, I think this could avoid artifacts across flat
> surfaces, but it could interfere with the cases where you just want
> direct topology-length without any extra calculations over the top.
> 
>> If we don't want to go down the path of trying to implement that, I would be
>> in favor of option 2.  Or maybe a variant of that where you provide a slider
>> that goes from 0->1 to say what proportion to consider topological distance
>> vs distance in 3-space.
> 
> Not sure a slider is really needed, we dont have a good place for this
> in the UI at the moment either.
> 
>>> --
>>> - Campbell
>>> _______________________________________________
>>> Bf-modeling mailing list
>>> Bf-modeling at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-modeling
>> 
>> 
>> 
>> _______________________________________________
>> Bf-modeling mailing list
>> Bf-modeling at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-modeling
> 
> 
> 
> -- 
> - Campbell
> _______________________________________________
> Bf-modeling mailing list
> Bf-modeling at blender.org
> http://lists.blender.org/mailman/listinfo/bf-modeling
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-modeling/attachments/20130618/efab230c/attachment.html>