[Bf-taskforce25] Modifier Layout Proposal

[Nathan Vegdahl]

> In my own uses of Blender I have much *much* larger
> constraint stacks than modifier stacks

Actually, I think I confused myself.  I use constraints a lot more
frequently, but per-object the stacks are actually shorter.  So
never-mind on that point.

I'd still like to see constraints in their own tab, though.
Especially if there are plans to at some point add the ability to
visualize multiple selection's data simultaneously (which I got the
impression was a target for some point, even if not for 2.5).

--Nathan V

On Fri, Jun 5, 2009 at 6:59 PM, Nathan Vegdahl<cessen at cessen.com> wrote:
> Come to think of it, yeah, this seems like a solution looking for a
> problem.  Things are good as-is.
>
>> This can even be a nice consistent thing in other lists
>> like constraints too.
>
>   In general I assumed this discussion was for both the modifier
> stack and the constraint stack, even though it wasn't explicitly
> stated.
>   Of course both stacks should be kept 100% consistent in their
> interface (as well as any other similar kinds of stacks).
>
>   In fact, I'd like to see constraints moved to their own tab just as
> modifiers have.  In my own uses of Blender I have much *much* larger
> constraint stacks than modifier stacks, and the constraint stack is
> frequently something I want to quickly find.  If modifiers deserve
> their own tab, I feel like constraints definitely do.
>
> --Nathan V
>
> On Fri, Jun 5, 2009 at 4:34 PM, Matt Ebb<matt at mke3.net> wrote:
>>
>> On 06/06/2009, at 8:32 AM, Brecht Van Lommel wrote:
>>
>>> With the current modifier stack, taking up a full tab, you can see and
>>> edit all modifiers immediately.
>> ...
>>
>>> Keeping the navigation hierarchy as flat as possible is a good thing
>>> in
>>> my opinion.
>>
>> +1
>>
>> I would definitely not like to have to click on individual modifiers
>> to see their settings. One of the advantages of Blender's modifier
>> stack over Max's for example is that you *can* see everything at a
>> glance. It lets you get a good overview of what's going on to your
>> objects, and it makes debugging problems much easier. If you're trying
>> to figure out why something isn't working (for example, an unbound
>> mesh deform that you'd forgotten about), having to go through your
>> objects, selecting each modifier one after the other to inspect it
>> would be very tedious.
>>
>> Simplicity is also the key here, some of these proposals seem very
>> over-complicated with un-obvious rules that are not really consistent
>> with other things in Blender either - "drag this here then click on
>> this and shit click on this:. It's a lot of 'interface massaging'
>> needed just to do something as basic as see your modifiers, and that's
>> not even using them to get work done.
>>
>> I'm not really sure what the problem is here that requires such
>> complicated solutions. If the issue is just that you want to see one
>> modifier at a time, it should be possible to do that easily with the
>> current system. We already have collapsing for modifiers, we could
>> just add a shortcut like ctrl-clicking (+ rmb menu) on a disclosure
>> triangle collapses all other modifiers and opens the one clicked on,
>> for example. This can even be a nice consistent thing in other lists
>> like constraints too.
>>
>>>  and even in that case I
>>> think a modifier grouping/folders type thing would be more useful.
>>
>> Now we're getting into nodes territory ;)
>>
>> cheers
>>
>> Matt
>> _______________________________________________
>> Bf-taskforce25 mailing list
>> Bf-taskforce25 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>
>