[Bf-committers] Vertex Pinning

patrick boelens p_boelens at msn.com
Mon Mar 24 01:36:03 CET 2014


Thanks for your response Campbell! Answers are inline.

> Date: Mon, 24 Mar 2014 10:34:26 +1100
> From: ideasman42 at gmail.com
> To: bf-committers at blender.org
> Subject: Re: [Bf-committers] Vertex Pinning
> 
> Pinning on its own is relatively simple to add, first I'd like to find
> if this is really worth adding from user POV, given you can already
> hide vertices to avoid editing them.
> 
> In fact we discussed this with some of the gooseberry artists and they
> didn't think this was so useful / important to add.

Hiding works fine in some cases, but the disadvantage here is that you lose the overview of those vertices (+ adjacent edges/ faces) and thus the final result. A quick example that comes to mind could be a low/ mid-poly skirt. You want to deform the skirt to have some pleads and creases using proportional editing, but want to leave the band at the top as is (let's assume it's fit to a character). Hiding the vertices works, but you won't be able to see the full skirt as you're pushing and pulling around the model, making it harder to estimate what looks good.

Another example could be a face for instance, where you're making shapekeys for the eyelids, but it's important the brows never move.

I've personally actively missed this feature several times, so it's not really a spur-of-the-moment thing for me. =)

> One thing thats still not clear to me is when should tools support this?
> 
> - Should edges between pinned vertices be subdivided?
> 
> - Should assigning vertices to a group skip pinned vertices?
> 
> - Should the rip tool allow pinned vertices to be ripped?
> 
> I think we should be clear about where pinning applies to avoid adding
> some feature then getting a steady stream of bug reports when users
> notice some tool doesn't respect pinned vertices.
> 
> If we limit pinning to transform + deformation tools then this could
> work (grab, rotate... etc + smooth, snap, warp, blend-from-shape)
> ...  but not attempt to support this for every tool (don't make this a
> second 'hide' option).

I agree this should be clear. To me, the real value lies in excluding certain vertices from transformation tools like the ones you mentioned (including blend-from-shape which I haven't touched yet). So a 'no' on Vertex Group assignment skipping pinned vertices from my end. As for subdiving edges, I quite like the way it's handled right now; just move what's not pinned, and leave pinned ones alone. It doesn't feel weird or unintuitive I think.

Rip Tool for me sounds like a gray area. On one hand, pinned = pinned = pinned, meaning it can't move. On the other hand though, usability-wise it would be a drag to have to unpin, rip, drag, repin. I'm not feeling too strongly either way, though I think I'm leaning towards not respecting pinning in this case.

One other case I considered was during sculpting, but for the sake of scope and due to the fact that there already is a Mask brush I would probably leave it at Edit mode mesh editing only.

Same for deformation modifiers and the like; these can already be controlled better by vertex groups and would just lead to clutter and (user) confusion i.m.h.o.

> One more thing...
> The possability to have laplacian deform in editmode (to work like
> pinned UV's), would be a really nice feature.

I definitely thought about functionality this, but decided it would probably be a rarely used feature and hard to code (I was originally imagining this with regards to rotate, scale, to sphere and such). I agree Laplacian Smooth might be a good (isolated) candidate for this though. On the other hand, where would we draw the line? Should regular Smooth respect pinning as well? According to my earlier definition, yes. But how this would look/ act in practice I'm not too sure about.

> ----
> 
> Regarding internals...
> 
> I'm more concerned long term with tools having to check both
> `BM_ELEM_HIDDEN` and some `BM_ELEM_PIN` flag.
> 
> Though some inline function could work...
> 
> `BM_elem_flag_test(ele, BM_ELEM_HIDDEN)`
> 
> ... could be replaced with a macro/fincion...
> 
> ` BM_elem_is_editable(ele)`
> ---
> inline bool BM_elem_is_editable(BMElem *ele)
> {
>     char testflag = (BM_ELEM_HIDDEN | BM_ELEM_PIN);
>     return (BM_elem_flag_test(ele, testflag) == testflag);
> }

Sounds good to me! Definitely a lot cleaner and more clear. =)


Regardless of if this will make it into Blender, I would really like this feature working for myself. The main problems I'm facing now that I can't quite solve though are the undo/ redo situation I described and the BM_ELEM_PINNED flag getting cleared after toggling out and back into Edit mode. Any chance you could give me some pointers on these issues? I for the life of me can't seem to find where the flag is being cleared.

Cheers and thanks again,
Patrick
 
> On Mon, Mar 24, 2014 at 3:28 AM, patrick boelens <p_boelens at msn.com> wrote:
> > Hi Antony,
> >
> > I'm not at all familiar with Blender's codebase, so could you give me a fix proposal? 1 << 6 is unused; is it safe to push BM_ELEM_DRAW and BL_ELEM_INTERNAL_TAG back one, or could that cause problems?
> >
> > Cheers,
> > Patrick
> >
> >> Date: Sun, 23 Mar 2014 10:13:13 +0200
> >> From: kalast at gmail.com
> >> To: bf-committers at blender.org
> >> Subject: Re: [Bf-committers] Vertex Pinning
> >>
> >> One basic flaw:
> >>
> >> hflag is a character so you are causing an overflow with
> >>
> >> BM_ELEM_INTERNAL_TAG or it may simply be ignored.
> >> _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> 
> 
> 
> -- 
> - Campbell
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
 		 	   		  


More information about the Bf-committers mailing list