Thanks for your response Campbell! Answers are inline.
> Date: Mon, 24 Mar 2014 10:34:26 +1100
> From: [email protected]
> To: [email protected]
> 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 <[email protected]> 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: [email protected]
> >> To: [email protected]
> >> 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
> >> [email protected]
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >
> > _______________________________________________
> > Bf-committers mailing list
> > [email protected]
> > http://lists.blender.org/mailman/listinfo/bf-committers
>
>
>
> --
> - Campbell
> _______________________________________________
> Bf-committers mailing list
> [email protected]
> http://lists.blender.org/mailman/listinfo/bf-committers
_______________________________________________
Bf-committers mailing list
[email protected]
http://lists.blender.org/mailman/listinfo/bf-committers
