[Bf-taskforce25] Modifier Layout Proposal

[Nathan Vegdahl]

In a way that is what he's suggesting, I think: read his second suggestion.
Sure, technically it's all in the same window.  But it could be split
into two sub-windows: one that displays the list of modifiers, and one
that shows the settings for the currently selected modifier(s).  This
is actually very close to workflow you suggest.

In any case, I do think that if the simulation features are to be in
the modifier system, then their settings need to be in the same place
as other modifiers' settings.  Basically, if they're modifiers, then
they need to really be modifiers, and they need to behave like the
rest of the modifiers, including where their settings are.  Maybe we
can move *all* modifier settings elsewhere.  But they should all be
found in the same place, regardless of the type of the modifier.

If this doesn't make sense for the simulation features, then I'd
suggest that they don't belong in the modifier stack.

--Nathan V

On Mon, May 25, 2009 at 8:14 PM, Daniel Salazar - 3Developer.com
<zanqdo at gmail.com> wrote:
>  I have to strongly (as in a strength that could easily destroy
> adamantium) disagree with putting 150 buttons on a modifier just to
> have everything in one place. We actually have to move AWAY from that.
> for example in the case of nodes, let the nodes make the connections
> and have *another* window in charge of displaying what's inside of the
> current node. Same goes for complex modifiers. It is a PITA in 2.4X,
> sure, but that can be helped in other smarter ways.
>
> Please have a look at this video to see what I mean:
> http://aviary.com/tools/peacock
>
> Daniel Salazar
> Cel: (506) 8366 8384
> Offi: (506) 2219 0511
> www.3developer.com
>
>
>
> On Mon, May 25, 2009 at 8:16 PM,  <bf-taskforce25-request at blender.org> wrote:
>> Send Bf-taskforce25 mailing list submissions to
>>        bf-taskforce25 at blender.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>        http://lists.blender.org/mailman/listinfo/bf-taskforce25
>> or, via email, send a message with subject or body 'help' to
>>        bf-taskforce25-request at blender.org
>>
>> You can reach the person managing the list at
>>        bf-taskforce25-owner at blender.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Bf-taskforce25 digest..."
>>
>>
>> Today's Topics:
>>
>>   1. Modifier Layout Proposal (Wahooney)
>>   2. Modifiable Particle Systems... (Wahooney)
>>   3. Re: Modifier Layout Proposal (Rob Cozzens)
>>   4. Re: Modifier Layout Proposal (Nathan Vegdahl)
>>   5. Re: Modifier Layout Proposal (Brian Staub)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Mon, 25 May 2009 21:20:11 +0200
>> From: Wahooney <wahooney at wahooney.net>
>> Subject: [Bf-taskforce25] Modifier Layout Proposal
>> To: "The Blender 2.5 TaskForce" <bf-taskforce25 at blender.org>
>> Message-ID: <4A1AEF6B.2040206 at wahooney.net>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> An HTML attachment was scrubbed...
>> URL: http://lists.blender.org/pipermail/bf-taskforce25/attachments/20090525/cc331a34/attachment-0001.htm
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Mon, 25 May 2009 21:37:02 +0200
>> From: Wahooney <wahooney at wahooney.net>
>> Subject: [Bf-taskforce25] Modifiable Particle Systems...
>> To: "The Blender 2.5 TaskForce" <bf-taskforce25 at blender.org>
>> Message-ID: <4A1AF35E.6070107 at wahooney.net>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> An HTML attachment was scrubbed...
>> URL: http://lists.blender.org/pipermail/bf-taskforce25/attachments/20090525/00148307/attachment-0001.htm
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Mon, 25 May 2009 13:27:39 -0700
>> From: Rob Cozzens <robcozzens at gmail.com>
>> Subject: Re: [Bf-taskforce25] Modifier Layout Proposal
>> To: "The Blender 2.5 TaskForce" <bf-taskforce25 at blender.org>
>> Message-ID:
>>        <cf6ca0a0905251327y7cdfa968j90bb6d075a6d6865 at mail.gmail.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> +1 +1 +1!
>>
>> On May 25, 2009 12:20 PM, "Wahooney" <wahooney at wahooney.net> wrote:
>>
>>  Some ideas were kicked about on IRC about a few changes that could be made
>> to the way the modifier panel works.
>>
>> = Keep modifier settings in the modifier panel =
>>
>> Thomas added the beginnings of the cloth settings tonight, and although it's
>> looking cool so far it pointed out a fundamental flaw. You are adding the
>> modifier in one panel in Blender and you're changing it's settings in
>> another?! That is quite counter intuitive to a new user and most probably a
>> break in workflow for experienced users (I'm somewhere in between those
>> extremes and it's grinding my goat already ;) )
>>
>> = Compact the modifier stack =
>>
>> The modifier stack can be reduced in total size by quite a bit actually. If
>> the stack were represented as a list it can take up far less space and it
>> can allow for a helpful mechanic: The user selects a modifier from the list
>> and only those settings are shown, saving space and reducing some clutter,
>> but we can also leverage the current advantage of having multiple modifiers'
>> settings visible by allowing the user to select multiple modifiers from the
>> list. The visible modifier's settings can be drawn in the order that they
>> appear in the stack and that selection can even be locked by the user and
>> saved into the *NA (DNA,RNA I'm not sure which :P), so a user can set up
>> their environment to modify a particular object in the way that they need
>> for the given object, ie. A setup with consecutive SimpleMods and SubSurfs,
>> chances are if a user were going to animate that object the SubSurfs
>> probably won't be touched and their settings should probably be hidden.
>>
>> Note: I know that a stack item can be collapsed into a smaller size, but
>> sometimes that's not small enough ;)
>>
>> The list that holds the items can also perhaps have drag 'n drop reordering
>> (allowing the reordering buttons in the current modifier system to take the
>> boot) and display the Show/Hide buttons for Render/Viewport/Editing/Cage
>> that currently reside in the modifier settings.
>>
>> That's all from me for now.
>>
>> Keith.
>>
>> _______________________________________________
>> Bf-taskforce25 mailing list
>> Bf-taskforce25 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.blender.org/pipermail/bf-taskforce25/attachments/20090525/a7296fac/attachment-0001.htm
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Mon, 25 May 2009 14:17:10 -0700
>> From: Nathan Vegdahl <cessen at cessen.com>
>> Subject: Re: [Bf-taskforce25] Modifier Layout Proposal
>> To: "The Blender 2.5 TaskForce" <bf-taskforce25 at blender.org>
>> Message-ID:
>>        <bd1b4c730905251417s3bf99cf5q70793adf91ab0b53 at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>>> The modifier stack can be reduced in total size by quite a bit actually. If
>>> the stack were represented as a list it can take up far less space and it
>>> can allow for a helpful mechanic: The user selects a modifier from the list
>>> and only those settings are shown, saving space and reducing some clutter,
>>> but we can also leverage the current advantage of having multiple modifiers'
>>> settings visible by allowing the user to select multiple modifiers from the
>>> list.
>>
>> +1
>>
>> This sounds like a big usability improvement, IMO.  I would definitely
>> rather work with modifiers this way.
>> It would also allow for more easily comparing modifiers that are
>> distant from each other in the stack, which I've needed to do on
>> occasion.
>>
>> --Nathan V
>>
>> On Mon, May 25, 2009 at 12:20 PM, Wahooney <wahooney at wahooney.net> wrote:
>>> Some ideas were kicked about on IRC about a few changes that could be made
>>> to the way the modifier panel works.
>>>
>>> = Keep modifier settings in the modifier panel =
>>>
>>> Thomas added the beginnings of the cloth settings tonight, and although it's
>>> looking cool so far it pointed out a fundamental flaw. You are adding the
>>> modifier in one panel in Blender and you're changing it's settings in
>>> another?! That is quite counter intuitive to a new user and most probably a
>>> break in workflow for experienced users (I'm somewhere in between those
>>> extremes and it's grinding my goat already ;) )
>>>
>>> = Compact the modifier stack =
>>>
>>> The modifier stack can be reduced in total size by quite a bit actually. If
>>> the stack were represented as a list it can take up far less space and it
>>> can allow for a helpful mechanic: The user selects a modifier from the list
>>> and only those settings are shown, saving space and reducing some clutter,
>>> but we can also leverage the current advantage of having multiple modifiers'
>>> settings visible by allowing the user to select multiple modifiers from the
>>> list. The visible modifier's settings can be drawn in the order that they
>>> appear in the stack and that selection can even be locked by the user and
>>> saved into the *NA (DNA,RNA I'm not sure which :P), so a user can set up
>>> their environment to modify a particular object in the way that they need
>>> for the given object, ie. A setup with consecutive SimpleMods and SubSurfs,
>>> chances are if a user were going to animate that object the SubSurfs
>>> probably won't be touched and their settings should probably be hidden.
>>>
>>> Note: I know that a stack item can be collapsed into a smaller size, but
>>> sometimes that's not small enough ;)
>>>
>>> The list that holds the items can also perhaps have drag 'n drop reordering
>>> (allowing the reordering buttons in the current modifier system to take the
>>> boot) and display the Show/Hide buttons for Render/Viewport/Editing/Cage
>>> that currently reside in the modifier settings.
>>>
>>> That's all from me for now.
>>>
>>> Keith.
>>>
>>> _______________________________________________
>>> Bf-taskforce25 mailing list
>>> Bf-taskforce25 at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>>
>>>
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Mon, 25 May 2009 19:16:39 -0700 (PDT)
>> From: Brian Staub <brian.staub at yahoo.com>
>> Subject: Re: [Bf-taskforce25] Modifier Layout Proposal
>> To: "The Blender 2.5 TaskForce" <bf-taskforce25 at blender.org>
>> Message-ID: <371331.89152.qm at web33206.mail.mud.yahoo.com>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> +1    ;)
>>
>>
>>
>> ________________________________
>>
>>
>> ________________________________
>> From: Nathan Vegdahl <cessen at cessen.com>
>> To: The Blender 2.5 TaskForce <bf-taskforce25 at blender.org>
>> Sent: Monday, May 25, 2009 4:17:10 PM
>> Subject: Re: [Bf-taskforce25] Modifier Layout Proposal
>>
>>> The modifier stack can be reduced in total size by quite a bit actually. If
>>> the stack were represented as a list it can take up far less space and it
>>> can allow for a helpful mechanic: The user selects a modifier from the list
>>> and only those settings are shown, saving space and reducing some clutter,
>>> but we can also leverage the current advantage of having multiple modifiers'
>>> settings visible by allowing the user to select multiple modifiers from the
>>> list.
>>
>> +1
>>
>> This sounds like a big usability improvement, IMO.  I would definitely
>> rather work with modifiers this way.
>> It would also allow for more easily comparing modifiers that are
>> distant from each other in the stack, which I've needed to do on
>> occasion.
>>
>> --Nathan V
>>
>> On Mon, May 25, 2009 at 12:20 PM, Wahooney <wahooney at wahooney.net> wrote:
>>> Some ideas were kicked about on IRC about a few changes that could be made
>>> to the way the modifier panel works.
>>>
>>> = Keep modifier settings in the modifier panel =
>>>
>>> Thomas added the beginnings of the cloth settings tonight, and although it's
>>> looking cool so far it pointed out a fundamental flaw. You are adding the
>>> modifier in one panel in Blender and you're changing it's settings in
>>> another?! That is quite counter intuitive to a new user and most probably a
>>> break in workflow for experienced users (I'm somewhere in between those
>>> extremes and it's grinding my goat already ;) )
>>>
>>> = Compact the modifier stack =
>>>
>>> The modifier stack can be reduced in total size by quite a bit actually. If
>>> the stack were represented as a list it can take up far less space and it
>>> can allow for a helpful mechanic: The user selects a modifier from the list
>>> and only those settings are shown, saving space and reducing some clutter,
>>> but we can also leverage the current advantage of having multiple modifiers'
>>> settings visible by allowing the user to select multiple modifiers from the
>>> list. The visible modifier's settings can be drawn in the order that they
>>> appear in the stack and that selection can even be locked by the user and
>>> saved into the *NA (DNA,RNA I'm not sure which :P), so a user can set up
>>> their environment to modify a particular object in the way that they need
>>> for the given object, ie. A setup with consecutive SimpleMods and SubSurfs,
>>> chances are if a user were going to animate that object the SubSurfs
>>> probably won't be touched and their settings should probably be hidden.
>>>
>>> Note: I know that a stack item can be collapsed into a smaller size, but
>>> sometimes that's not small enough ;)
>>>
>>> The list that holds the items can also perhaps have drag 'n drop reordering
>>> (allowing the reordering buttons in the current modifier system to take the
>>> boot) and display the Show/Hide buttons for Render/Viewport/Editing/Cage
>>> that currently reside in the modifier settings.
>>>
>>> That's all from me for now.
>>>
>>> Keith.
>>>
>>> _______________________________________________
>>> Bf-taskforce25 mailing list
>>> Bf-taskforce25 at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>>
>>>
>> _______________________________________________
>> Bf-taskforce25 mailing list
>> Bf-taskforce25 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>
>>
>>
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.blender.org/pipermail/bf-taskforce25/attachments/20090525/e5d09f2d/attachment.htm
>>
>> ------------------------------
>>
>> _______________________________________________
>> Bf-taskforce25 mailing list
>> Bf-taskforce25 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>
>>
>> End of Bf-taskforce25 Digest, Vol 9, Issue 28
>> *********************************************
>>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>