Groups and Layers work completely similarly.
Multiple Objects get into layers or groups, objects can get into more than one layer or group… What’s the difference?
However, they just have a different purpose. Groups are for uses with particle system, linking. Layers are for hiding and showing things, render layers.
But is it really worth having two separate things? Why not re-purpose the layers to work for both cases, this way saving space? Less, without losing functionality, is better, isn’t it?
Maybe I missed something about groups. Any arguments on why they should remain in blender?
Groups can’t be accessed from the 3D View header like layers
Couple operators take a BoolVectorProperty to determine layer states, operators dealing with groups usually work on a single group at a time taking a StringProperty (there’s no StringVectorProperty, a CollectionProperty would be required to allow for multiple StringProperties)
In my opinion, the layer system could be dropped provided that the group system is enhanced to fill the functional gap - some widget to quickly change visibility (like with current layer widget).
The word and associated concept of “layer” could be repurposed for mono-hierarical relationalships in the outliner (a layer as parent and 0…n objects as children, with support for nesting, but no object being in 2 sibling layers). As all objects of a group needed to be children of the same layer, it would make sense to parent the group to a layer:
Layer 1
|
|_ Group 1
| |_ Object A
| |_ Object B
| |_ Object C
|
|_ Group 2
|_ Object D
|_ Object E
Layer 2
|_ ...
For the poly-hierarchical groups, the node editor could be used to view and edit the relationships (but with the limitation of not allowing groups to be nested in groups? If possible, this should actually be allowed, no circular references however).
The layer system could be used to support collaboration in Blender. A layer could originate from another .blend or even be accessed remotely (but read-only).
in maya you have groups and layers too. You get visual layers, you get animation layers. All sorts of layers.
Groups are used to control objects there- more in terms of coordinates. Visual layers are used to show/hide multiple objects. But also TEMPLATE (or R- lock) them.
In blender groups are used more like a way to tag objects. They dont affect hierarchy and can not be used in the same way maya’s groups tend to be used in rigging.
Blender layers can show and hide, but they can not be locked, nor named. They seem to be for quick and simple scene visibility management.
They are not available during edit mode.
This would be solved with a proper layer manager, where the user could create as many or as little layers as he wants, name them, lock them… etc…
Groups can’t be accessed from the 3D View header like layers
Irrelevant.
In my opinion, the layer system could be dropped provided that the group system is enhanced to fill the functional gap - some widget to quickly change visibility (like with current layer widget).
So you, want to move the layer functionality to groups, not visa versa…
I don’t really see a difference.
However, the main problem I see with that, that removing one of the two would break backward compatibility. And users use layers far more often than groups!
Of course, making such changes is not something important. I just think it makes sense.
IMHO we need in fact a better Layer System and a Better Group System. I’m not sure about marge both. Thinking in Dupli Group and Asset Management usage it don’t look that great to have just Layers and categorizing Objects by Group for simple visualization separation ( instead Layers ) can be too much slow. There’s a mid point that fit everything?
I don’t see how groups and layers are related in any way. They provide completely different functionality. Many people seem to think groups can or should be used to organize the scene, but that’s not the case. They are mainly there to instance objects and build library assets. I agree the term groups might be misleading, especially with the Photoshop concept of groups in mind. If anything, there could be a third thing that can be used to contextually group things, also for easier selection in the outliner.
Thanks for that explanation Sebastian. I always use layers to organize my scene and never really understood what groups are for. Is there a good tutorial out there about properly building and using library assets. I am so bad at that, that I always find myself renaming old blend files and reusung them.
I don’t want start the usual blender vs World complain, but I really prefer organize my scene with addon like Layer Management, like every software out there (excluding Zbrush). An example is modo Item List: in a single window all the functions of our outliner and layers: more simple, better organized and more clear. IMO an outliner evolution is a must for blender usability.
I don’t see how groups and layers are related in any way. They provide completely different functionality.
My point is, not that they have the same functionality, they don’t, but that they work in a similar way: They are both containers of objects.
And because they are both containers of objects, why not move all functionality from one to another and remove one of them?
That is, actually give layers instancing and library asset functionality. If layers had this functionality, would groups have a purpose then?
Nope, you really gotta separate the two. Layers are also a crucial way of managing renderlayers, masks, etc. It’s just not compatible with the group functionality.
Groups should not be called groups, you can make a group of object with empty’s, groups are for instancing etc, so it’ not the same as layers or empty’s.
I would really like to know how would you implement instancing with layers?
The exact same way they are implemented in groups? o.O
You have a bunch of objects in layer 2, then you have a particle emitter in layer 1, that emitts objects that are in layer 2.
Layers and groups are two totally different tools.
With layers you can quickly hide show objects.
Groups more define relationships.
I’ll repeat myself again:
I know how different they are for how they are used and what functionality they have.
That is, you can’t use layers for instances, you can’t use groups for render layers or object hiding, so on.
But they don’t seem different at all on how they are defined - I see them as, basically, “belongs to” stickers on an object:
object1 :: belongs to :: Layer1,Layer2,…
object1 :: belongs to :: Group1,Group2,…
I believe that one type of “sticker” can be used for both purposes - relationships and hiding.
So, if group functionality was ported to layers, they would not only be for hiding stuff, they would also define relationships.
I understand what you’re getting at here, but I would personally prefer the two things to be separated by their usage.
If you’ll allow a metaphorical parallel… You have two containers for holding paperwork. Functionally, they work the same way. you open them both up and you put papers in them. However, one of those containers is for keeping your papers organized (a filing cabinet) and the other is temporary storage prior to removal (a trash bin). You might get some pretty strange looks in an office if you were to suggest combining those two containers into one.
Objects can belong in more than one layer. So you can place them in layers such as “All hardware parts”, “All cloth parts”, so on, and in other layers for sorting visibility…
