Layer management (thread broken)

The interface, modeling, 3d editing tools, import/export, feature requests, etc

Moderators: jesterKing, stiv

thorwil
Posts: 103
Joined: Tue Sep 09, 2003 10:30 am

Layer management (thread broken)

Postby thorwil » Wed Nov 26, 2003 9:59 pm

Hi!

I've setup a page to collect and organize ideas on how to improve and extent layer management.

Last updated: 2003-11-30
http://wrstud.urz.uni-wuppertal.de/~ka0 ... index.html

Please read it and feel free to participate!
Last edited by thorwil on Sat Dec 06, 2003 7:00 pm, edited 2 times in total.

pinhead_66
Posts: 107
Joined: Wed Oct 16, 2002 10:09 am
Location: Belgium

Postby pinhead_66 » Thu Nov 27, 2003 9:07 pm

hi Thorwil

I realy dig the layer proposal. It would simplify life for many, check with monkeyboy, maybe you can talk this stuff over with him, he's making real decent proposals two


greets
pinhead_66

thorwil
Posts: 103
Joined: Tue Sep 09, 2003 10:30 am

Postby thorwil » Fri Nov 28, 2003 4:12 pm

Some new stuff on my page, please check it out!

And to pinhead_66:
Nice you like it, but it would help if you could state what you would prefer from the different concepts.

Karim
Posts: 30
Joined: Mon Jun 30, 2003 7:15 pm

Postby Karim » Sun Nov 30, 2003 2:16 am

Thorowil,

Reasonable modifications. I like your indicators fine. I would make one change though:

The Render Layer toggle & indicator should indicate a NON-rendered layer, rather than a rendered layer. My reasoning is that Generally, most layers will be set to be rendered, so having only non-rendered layers indicated will be less cluttered.

Also, the default states of a layer would be to render, so newbies would have one less thing to deal with when learning the program.

thorwil
Posts: 103
Joined: Tue Sep 09, 2003 10:30 am

Postby thorwil » Sun Nov 30, 2003 11:36 am

Karim,

you're right. I didn't think about it this way, it seemed easier to indicate rendering as something additional.
I will present a modified mockup soon. Stay tuned ;-)

Thanks!

pinhead_66
Posts: 107
Joined: Wed Oct 16, 2002 10:09 am
Location: Belgium

Postby pinhead_66 » Sun Nov 30, 2003 12:05 pm

Hm,
In my view the latest mokup is a bit too grouded


also, monkeyboi was playing with the use of color, I think it would be best to keep color use to a minimum, especially bright colors, because they can draw the attention from the 3dWindow.

also, use of color, if used, should be general for whole the gui, question of being consistent

Keep the layer management tool as simple as possible
as you did. Make it possible to name layers and have an overvieuw of them
the functionality of rendering a layer or not is allready there and works like a charm so why change a thing that is good.

More layers would be cool, but in some cases less too :)


greets and keep up the great work
pinhead_66

thorwil
Posts: 103
Joined: Tue Sep 09, 2003 10:30 am

Postby thorwil » Sun Nov 30, 2003 3:14 pm

I've added new mockups on my page. Please take a look and comment (the second "Update" section).


pinhead_66 wrote:Hm,
In my view the latest mokup is a bit too grouded


Which one, Karim's or mine, and what do you mean with grouded?

I agree with your thoughts about colour. However, I introduced some colour in my new mockups, because grayscale was not enough to make things clear.

the functionality of rendering a layer or not is allready there and works like a charm so why change a thing that is good.


Having rendering and visibility in 3d view combined is good because of the simplicity. But it's nice to have only some of the layers that will be rendered visible to make editing easier. And as it is now, you have to toggle layers for every test render then.
Having it all integrated into the buttons is only one possibility. I could imagine having 2 sets of 20 buttons each. 1 for visibility, 1 for rendering. It could also allow to easily see what will be rendered in 3d view by switching between the sets.

More layers would be cool, but in some cases less too :)


The space to be saved by less buttons is not worth it, I think. But could you imagine to use some of the keyboard shortcuts for upper layers for different things? What would you like to assign them to?

p_vertex_
Posts: 25
Joined: Sun Nov 02, 2003 10:46 am

Postby p_vertex_ » Mon Dec 01, 2003 3:23 am

I am glad someone has taken the initiative to start looking at this. I like most of your proposal, but there are a few things I'd suggest:

1. Currently each layer is tied to a number key, which is one of the reasons that it's limited to only 20 layers. I'd like to see this constraint removed. Make the creation of layers like the creation of materials - there's no logical reason that you shouldn't be able to create as many layers as you need for a given project/scene. This would follow the current paradigm employed by almost every other mainstream software app that uses layers.

2. Be able to name groups of layers, and assign a key to the group (this may have been something you were suggesting, but it wasn't clear). One thing that slows me down is turning groups of layers on and off (the same groups), over and over. It's wasted effort.

3. I like the idea of having small icons to represent different states of each layer.

theeth
Posts: 1184
Joined: Wed Oct 16, 2002 5:47 am
Location: Montreal
Contact:

Postby theeth » Mon Dec 01, 2003 3:39 am

Unless the system is completely rewritten, the upper limit is 32 layers.

Martin
Life is what happens to you when you're busy making other plans.
- John Lennon

thorwil
Posts: 103
Joined: Tue Sep 09, 2003 10:30 am

Postby thorwil » Mon Dec 01, 2003 11:18 am

p_vertex_,

about abstracting layers from shortcuts/buttons:
I adressed that under "More than 20". Of course this has to be worked out.

About grouping of layers:
Curently a layer is a selection/group of objects represented by 1 of the 20 buttons, with it's visibility/renderabilty toggable with that button or the associated shortcut.
I want to turn a layer into a selection/group of objects, tha can be associated with any (or none) of the buttons/shorcuts.
Besides putting layers into layers I have no idea how to do what you ask here for. And if I understand you right, then your taliking about toggling more than 1 button/layer with a single shortcut. Breaking the button/shortcut relation would be very bad, I think. If you toggle layers 2,3,4 with key 1, what should happen on keys 2,3,4?

It would make sense to have groups inside the layer manager. And groups within groups, if you like, just like a hierarchical filesystem. The user could assign up to 20 shorcuts/buttons to the groups (or even single objects within them). The state (visibility) of a parent group would top those of child groups (parent visible, child can be visible, parent hidden: all children hidden).
That should be quite a good solution for what you basicaly want, I think. How do you think about it?

p_vertex_
Posts: 25
Joined: Sun Nov 02, 2003 10:46 am

Postby p_vertex_ » Tue Dec 02, 2003 7:11 am

thorwil wrote:p_vertex_,

about abstracting layers from shortcuts/buttons:
I adressed that under "More than 20". Of course this has to be worked out.

About grouping of layers:
Curently a layer is a selection/group of objects represented by 1 of the 20 buttons, with it's visibility/renderabilty toggable with that button or the associated shortcut.

Just so we're on the same page: currently a layer is a selection/group of objects, any of which could be represented on one or more of the 20 layers, with their visibility/renderability toggleable with that button or the associated shortcut.

I want to turn a layer into a selection/group of objects, tha can be associated with any (or none) of the buttons/shorcuts.


The difference between what you describe here, and what you described previously may be subtle, but I don't quite see it. In one sense, a layer is a group of objects that is associated with a button/shortcut. Are you saying that you'd like to yank the direct relationship between buttons and layers?

Besides putting layers into layers I have no idea how to do what you ask here for.


I envision this working in one of two ways:

1. Create an entity that will function as a parent to the existing layer mechanism. Everything stays pretty much the same, except that you can create layer groups, each of which can represent any combination of layers. Selecting the group's name (via dropdown or some other means), activates all the layers associated with that group.

2. Start out with 1 default layer, and create layers dynamically as you build your scene (this is how it works in most other apps that use layers). Along with this, provide the ability to assign layers to groups as needed, so that activating the group will activate all of its associated layers. As with the previous method, any one layer can belong to any number of groups.

And if I understand you right, then your taliking about toggling more than 1 button/layer with a single shortcut. Breaking the button/shortcut relation would be very bad, I think. If you toggle layers 2,3,4 with key 1, what should happen on keys 2,3,4?


Initially, I was thinking about allowing shortcuts to be assigned dynamically, as layers, and groups of layers are created. Any given shortcut could toggle any indivdual layer, or any group.

However, this wouldn't be entirely necessary. Even having something like a dropdown menu with the names of the various layer groups (none of which would have shortcuts) would be an improvement. The only difference in terms of practical application is that the former method gives you a greater degree of flexibility.

It would make sense to have groups inside the layer manager. And groups within groups, if you like, just like a hierarchical filesystem. The user could assign up to 20 shorcuts/buttons to the groups (or even single objects within them). The state (visibility) of a parent group would top those of child groups (parent visible, child can be visible, parent hidden: all children hidden). That should be quite a good solution for what you basicaly want, I think. How do you think about it?


It sounds like we're talking about the same basic idea here. Even if it only provided the ability group layers only one level deep, it would be an improvement over the current system.

thorwil
Posts: 103
Joined: Tue Sep 09, 2003 10:30 am

Postby thorwil » Tue Dec 02, 2003 1:53 pm

p_vertex_ wrote:Just so we're on the same page: currently a layer is a selection/group of objects, any of which could be represented on one or more of the 20 layers, with their visibility/renderability toggleable with that button or the associated shortcut.


Are you saying that you'd like to yank the direct relationship between buttons and layers?


Yes!


1. Create an entity that will function as a parent to the existing layer mechanism. Everything stays pretty much the same, except that you can create layer groups, each of which can represent any combination of layers. Selecting the group's name (via dropdown or some other means), activates all the layers associated with that group.


So 1 layer could be in more than 1 group? That's interesting, but we have to think about its usefulness and the confusion it might cause. I assume you would like to store settings (visibilty) only per layer, not connected with the parent entity?!

How about using sets that store every buttons/layers state? You could switch between different settings for the same layers.


It would make sense to have groups inside the layer manager. And groups within groups, if you like, just like a hierarchical filesystem. The user could assign up to 20 shorcuts/buttons to the groups (or even single objects within them). The state (visibility) of a parent group would top those of child groups (parent visible, child can be visible, parent hidden: all children hidden). That should be quite a good solution for what you basicaly want, I think. How do you think about it?


It sounds like we're talking about the same basic idea here. Even if it only provided the ability group layers only one level deep, it would be an improvement over the current system.


What I explained about the problem of assigning shortcuts on different levels (groups of layers or single layers) is very important. I can't see where you adressed it.

I think it's best to step back, and take a look what we want as basic features:

- naming of layers
- setting rendering independent from visibilty
- locking of layers
- (optionaly) more than 20 layers, with free assignment of buttons/shortcuts to them

And you brought up:

- grouping of layers for activating/deactivating a group of layers at once
- allowing a layer to be in more than 1 group

You can have the first one (grouping) with my last concept. The only problem is visualisation. You would have buttons that affect a number of other buttons, while other buttons would only affect themselves. You can't group them in layout, because of their connection to shortcuts.
Having layers that are in more than one group would make it even worse.
Using sets of settings might be better for the purpose of switching on or off a group of layers. But that wouldn't work nicely with changeable assignemt of buttons/shortcuts.

Karim
Posts: 30
Joined: Mon Jun 30, 2003 7:15 pm

Postby Karim » Tue Dec 02, 2003 4:46 pm

Another thought that might add to this discussion is the following excerpt from a white-paper I wrote some time back for another interface proposal:

http://karimnassar.com/design/artemis/a ... tions.html
http://karimnassar.com/design/artemis/a ... html#stage
http://karimnassar.com/design/artemis/a ... tml#matrix

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.

p_vertex_
Posts: 25
Joined: Sun Nov 02, 2003 10:46 am

Postby p_vertex_ » Wed Dec 03, 2003 2:21 am

Instead of going down the same path again (your comments have allowed me to see some potential problems with my idea), let me just summarize what I'd like to see: 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:

- naming of layers
- setting rendering independent from visibilty
- locking of layers
- (optionaly) more than 20 layers, with free assignment of buttons/shortcuts to them

p_vertex_
Posts: 25
Joined: Sun Nov 02, 2003 10:46 am

Postby p_vertex_ » Wed Dec 03, 2003 2:26 am

Karim wrote:Another thought that might add to this discussion is the following excerpt from a white-paper I wrote some time back for another interface proposal:

http://karimnassar.com/design/artemis/a ... tions.html
http://karimnassar.com/design/artemis/a ... html#stage
http://karimnassar.com/design/artemis/a ... tml#matrix

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.


Interesting concept. It seems a little on the complicated side, but it would have helped if they'd described how you'd use this within a real problem space. It's not to say that this isn't a viable model, just that it's not clear as to exactly how one would benefit from using this model.


Return to “Interface & Tools”

Who is online

Users browsing this forum: No registered users and 0 guests