p_vertex_ wrote:... the ability to toggle different sets of layers on and off, where set membership is not exclusive. Sets, in and of themselves, would not be associated with buttons, nor would they need to have shortcuts (although the ability to assign a shortcut would be nice). The problem, as I've described it, is having to toggle multiple groups of layers on and off repeatedly throughout the development of a scene. The solution, as I've proposed it, is the ability to delegate this toggling function to another entity: a set or group. I'm not clear as to why this can't work as an adjunct to the criteria that you've specified:

So we would have layer buttons like now and another kind of buttons for groups of layers. I understand why you want to be able to toggle groups of layers at once. Would be useful, no doubt. But I very much dislike the idea of introducing an additional concept, that is very similiar but not entirely the same as the present. An the extra space needed for buttons exclusive to toggling groups. The need to differentiate the button types.

Last edited by thorwil on Sat Dec 06, 2003 6:55 pm, edited 1 time in total.

The concept of Stages, while not exactly what we are talking about does have a bit in common with the more advanced Layer ideas we're tossing about.

It's a bit like the movie strips in Flash. They can be nested and contain all kinds of objects. While editing, movie stips inside the current one behave like single objects. But you can doublclick on them, to edit their contents in place (you can still see stuff on the upper level). You can also edit movie strips standalone by entering them from the library.

Solidworks has Parts and Assemblies. A Part is a single body that can be very complicated, but there can be no disconnected parts inside it. Parts can be placed inside Assemblies. Assemblies can contain other Assemblies. Every part or Assembly is saved in its own file. You can edit Parts or Assemblies inside an Assembly.
It's very good for reusable parts and subassemblies. But it's complicated if you have to change things already included in several Assemblies (I think they should integrate a versioning system).

p_vertex_ wrote:... the ability to toggle different sets of layers on and off, where set membership is not exclusive. Sets, in and of themselves, would not be associated with buttons, nor would they need to have shortcuts (although the ability to assign a shortcut would be nice). The problem, as I've described it, is having to toggle multiple groups of layers on and off repeatedly throughout the development of a scene. The solution, as I've proposed it, is the ability to delegate this toggling function to another entity: a set or group. I'm not clear as to why this can't work as an adjunct to the criteria that you've specified:

So we would have layer buttons like now and another kind of buttons for groups of layers.

Did you miss the part above that states, specifically, Sets, in and of themselves, would not be associated with buttons...?

I understand why you want to be able to toggle groups of layers at once. Would be useful, no doubt. But I very much dislike the idea of introducing an additional concept, that is very similiar but not entirely the same as the present.

What are you getting at here? I'm talking about adding useful functionality to an already-exiting paradigm. Better that than a complete paradigm shift.

An the extra space needed for buttons exclusive to toggling groups. The need to differentiate the button types.

As I pointed out, the buttons are not an issue - there are other ways to represent sets. A popup menu, for example.

Just a note: it's not important to me whether or not this becomes part of your proposal. Either way, I consider it a feature request, and I think both its usefulness, and its ability to work with the existing layer mechanism, stands on its own merits. Being very much related to what you're proposing, I thought it might included - if not, no biggie.

p_vertex_ wrote:Did you miss the part above that states, specifically, Sets, in and of themselves, would not be associated with buttons...?

Oops, I'm sorry, it somehow slipped out of my mind.
So I have to replace button with some widget(s).

As I pointed out, the buttons are not an issue - there are other ways to represent sets. A popup menu, for example.

Do you mean something that brings up a menu where you can toggle sets of layers?
Please think about the impact on speed and oversight this might have, because of the indirect access to this functionality. How many number keys could you hit in the time needed for one operation of that kind? Of course, if you toggle layers mostly per mouse it's different.

Just a note: it's not important to me whether or not this becomes part of your proposal. Either way, I consider it a feature request, and I think both its usefulness, and its ability to work with the existing layer mechanism, stands on its own merits. Being very much related to what you're proposing, I thought it might included - if not, no biggie.

I see what you want in basic functionality. Could have used something like that myself often enough. And since you take the time to discuss things here, I do not want to ignore you. If I couldn't point out problems with your feature request I would feel obliged to include it in my proposal. That is not to say that I want to find problems. I'm looking for solutions in the end!

Please take a look at my last proposal. I think that the ability to put groups into groups and to assign shortcuts on all levels should fullfill your needs.

If not, I would like to see a little more concrete proposal from your side, so we could compare and discuss it.
But I will include your ideas on my page anyway, since it was meant to collect ideas after all.

p_vertex_ wrote:Did you miss the part above that states, specifically, Sets, in and of themselves, would not be associated with buttons...?

Oops, I'm sorry, it somehow slipped out of my mind.
So I have to replace button with some widget(s).

I'd think you'd also have to dimiss the concern you brought up when you mentioned this - that another type of button would confusing. No buttons, no confusion.

Do you mean something that brings up a menu where you can toggle sets of layers?

Yes...the same kind of menu that's used for materials, textures, etc.

Please think about the impact on speed and oversight this might have, because of the indirect access to this functionality. How many number keys could you hit in the time needed for one operation of that kind?

5 layers = 5 keys. If the current desired "set" is comprised of 5 layers within a total of 10 layers that are being used, you run a much higher risk of selecting layers that are not within the desired set. What you are buying with the menu/set approach is accuracy, and with accuracy comes speed. One selection, and all layers with a given set become active. I don't see how this can compare unfavorably over selecting five separate layers.

Of course, if you toggle layers mostly per mouse it's different.

I'm not so sure it's all that different. You can make mistakes with shortcuts as easily as you can with the mouse. In fact, I'd posit that the mouse/menu approach is better, because in order to access layers via the keyboard, it will most likely require both hands, whereas with the mouse/menu approach, you do not have to remove your hand from the mouse in order to use it.

If not, I would like to see a little more concrete proposal from your side, so we could compare and discuss it.

p_vertex_ wrote:I'd think you'd also have to dimiss the concern you brought up when you mentioned this - that another type of button would confusing. No buttons, no confusion.

You're right.

Do you mean something that brings up a menu where you can toggle sets of layers?

Yes...the same kind of menu that's used for materials, textures, etc.

5 layers = 5 keys. If the current desired "set" is comprised of 5 layers within a total of 10 layers that are being used, you run a much higher risk of selecting layers that are not within the desired set. What you are buying with the menu/set approach is accuracy, and with accuracy comes speed. One selection, and all layers with a given set become active. I don't see how this can compare unfavorably over selecting five separate layers.

OK, so with a higher number of layers per set this becomes more interesting. With my own work it's rather 3 layers I would want to toggle at once (since with 2 this is not of interest).

Just an idea: Grouping layer buttons in fixed sets of 5, with every set toggable by RMB menu.

You can make mistakes with shortcuts as easily as you can with the mouse. In fact, I'd posit that the mouse/menu approach is better, because in order to access layers via the keyboard, it will most likely require both hands, whereas with the mouse/menu approach, you do not have to remove your hand from the mouse in order to use it.

Your fingers (keyboard usage) are very much faster than you can operate a mouse. It's well researched, but I have no time to search for some numbers on this right now.

If not, I would like to see a little more concrete proposal from your side, so we could compare and discuss it.

What are you looking for? A mockup?

A mockup would be great, but any further detail, like that it's supposed to be like current menu for material is good.

thorwil wrote:
OK, so with a higher number of layers per set this becomes more interesting. With my own work it's rather 3 layers I would want to toggle at once (since with 2 this is not of interest).

Just an idea: Grouping layer buttons in fixed sets of 5, with every set toggable by RMB menu.

This would impose an arbitrary constraint, and if there's no really, REALLY good reason for it, I'd elect to do something else. Arbitrary constraints make life more difficult - as they have for people that needed to exceed Blender's maximum vertex limit, maximum render size (I think that was one of them), maximum number of materials per mesh, etc.

Your fingers (keyboard usage) are very much faster than you can operate a mouse. It's well researched, but I have no time to search for some numbers on this right now.

This is true in some cases, but by no means all of them. Much of it depends on what your'e doing. If you're forced to switch context often between the mouse and the keyboard (which is exactly what's required in order to activate/deactivate layers), I'd suggest that this an inefficient implementation. Ultimately, it seems like you'd want to keep the context switching to a minimum.

The only thing I'm not clear on at the moment is the means by which the layer sets are managed - how a layer is added to or deleted from a set, and how a shortcut is assigned to a given set (this addresses your keyboard issue, by the way).

thorwil wrote:Just an idea: Grouping layer buttons in fixed sets of 5, with every set toggable by RMB menu.

This would impose an arbitrary constraint, and if there's no really, REALLY good reason for it, I'd elect to do something else.

The reason would be simplicity. Easy visualisation and nothing to setup for the user. But of course it's very limited.

About set management: The menu should never hide the buttons. If the mouse cursor is above a set entry, the
layer buttons that will be affected could be highlighted. And maybe their contents in 3d view too.

Regarding the object hierarchy concept, surely this is what the OOPS window should do. Currently it is for viewing only (and doesn't go down to such detail as vertex groups) but this could be added and then make it possible there to link and unlink objects, group objects, set visibility etc. It is a window that looks as if it should be really useful but unfortunately hasn't really gone anywhere.

thorwil wrote:
The reason would be simplicity. Easy visualisation and nothing to setup for the user. But of course it's very limited.

The challenge here is to provide good functionality for power users while not creating any more of a burden on new users. What if I have 11 layers that are currently being used for a scene? If I understand the constraint you've proposed, it means that instead of one set consisting of 11 layers, I now have to contend with 3 sets (2 that have five layers, and 1 that has one later). I don't see anything simple about this. In fact, if I have another collection of six layers I'd like to "group", I now have two more sets I have to contend with. Unforunately, this puts me right back where I started, having to remember which sets do what. There's no benefit at this point.

About set management: The menu should never hide the buttons. If the mouse cursor is above a set entry, the layer buttons that will be affected could be highlighted. And maybe their contents in 3d view too.

I'm not sure what I've ever said to indicate otherwise. Just the same, I might also disagree with this. A menu takes up whatever portion of the screen it needs in order to adequately present the user with the options they have. This is why they call them "popup" or "dropdown" menus - because they use the screen space only temporarily, AFTER WHICH the menu disappears, and the user gets to see the results of their selection. This is common behavior.

About set management: The menu should never hide the buttons. If the mouse cursor is above a set entry, the layer buttons that will be affected could be highlighted. And maybe their contents in 3d view too.

I'm not sure what I've ever said to indicate otherwise. Just the same, I might also disagree with this. A menu takes up whatever portion of the screen it needs in order to adequately present the user with the options they have. This is why they call them "popup" or "dropdown" menus - because they use the screen space only temporarily, AFTER WHICH the menu disappears, and the user gets to see the results of their selection. This is common behavior.

Bad formulation on my side: The 2 sentences were meant to be taken as 1 proposal: Do not hide buttons because they will be highlighted.
I say: If you can give the user a sense of what will happen in advance, then do it!

Besides, if you use a menu widget on the height of the button array, than the menu itself will appear above or below it, thereby not hiding buttons anyway.