[Bf-funboard] (Luke) Re: layers vs. groups, and "no render".

[Thorsten Wilms]

On Fri, Dec 05, 2003 at 04:50:33PM +1000, Luke Wenke wrote:
> 
> Since they can be in multiple "layers" at once, I think they should be
> called "groups". (So those 20 icons at the bottom would be "group buttons")
> The problem with that though is that there is already something in blender
> called groups...
> But I think it is more important to call those buttons "groups". I don't
> think the term "layer" should be used at all. This would be replaced by the
> word "group". So in the lamps buttons, instead of "layer only" it would be
> "groups only"... so the lamp would light up every single group it is in.

That's fine with me, since I used the term Layers only because that's what 
it's called now. But one might say the term Layer should be kept because 
of historical reasons / to not confuse long time users.

For the object manager it wouldn't make much sense to talk about Layers.
But Groups, I don't know since there could be single objects in the tree.

> It could number them 1 to 20, or perhaps a better thing to do would be to
> number them 1 to 0, then alt-1 to alt-0... when it is easy for people to
> learn the hotkeys. (I suggest 1 to 0 [1,2,3,4,5,6,7,8,9,0] rather than 0 to
> 9 because on the keyboard it goes 1 to 0).

Hmm, no change from now, besides you want to use "0" instead of "10"? 
Better mapping with keys, but that's not much of a problem now. And 
having the numbers going from 1 to 9, followed by 0 will look very strange.

> Notice that CloseTrees appears in both groups 2 and 3... in those previous
> proposals I'm not sure if that would be able to happen.

It's supposed to be able to happen. But I still have to think about _all_ 
the consequences of that concept.

> Other suggested features:
> - The ability to move, copy and delete objects using drag, ctrl-drag and
> delete.

Good. Should also be possible by more visible means.

> - Multiple objects or groups can be selected using shift-click or
> ctrl-click.

Shift-click yes, but ctrl-click? 


> - The ability to swap group numbers using context menus.

Please explain what you mean exactly / in more detail.


> The "m" command would probably need to be changed... 

I don't feel like talking about renaming and changing shortcuts right now, 
since more fundamental things should be discussed firts. And discussions about 
naming tend to be long and pointless.

> Well it could be handled like this....
> Currently if an object is in a few layers and at least one of the layers is
> visible, then that object is visible.
> A possibility could be that if at least one of the layers (groups) is set to
> "no render" then the object isn't rendered - even if that "no render" layer
> isn't visible. Or maybe the "no render" layer has to be visible to take
> effect.

No no, rendering should work exactly like visibility: if any of the "layers" 
the object is "in" is set to render, the object will be rendered.

But locking is realy problematic ...

> Well I guess the most straight-forward solution is to be able to set
> individual objects so they don't render. I think it should be independent of
> what layer/group it is in... so if you move an object to another
> layer/group, its rendering state stays the same. To make it easy to manage
> lots of objects as far as the rendering state goes, you could have a way of
> setting the rendering state of all of the selected objects, and also a way
> of selecting either all of the "no render" objects, or all of the "render"
> objects. (You can use "invert selection" to select the opposite property)

I think there's no point in using the "layer" system for less, that is, taking
functionality away. Especialy when you would have to create a new, additional 
concept.
The current system is just awesome for managing object visibility. But you might 
know what I wrote about advantages and disadvantages.


---
Thorsten