Your idea already defeat the concept of group.
The thing is that you can already order the objects in groups and this should make possible to assign by group some properties. Override any group setting by a “supergroup” setting is somewhat overkill the original idea.
i think the hole point in layers is that you can effect change in a allot of object at once
so maybe instead of coding the functionality needed for layers which can be difficult due to the legacy code
you can add the same functionality to groups with less effort again i maybe hallucinating here …
like in photoshop for example you can have a group that is inside a group and because the outside group (the super group) is hidden the inside one is too
the same goes for my suggestion you cane have a super group that have other groups and objects inside it and it override there individual settings
the only difference is that you can chose which one is the subergroup and it will be assigned that flag
opvisly it must be the outer group and you can’t have a super group within a supergroup
but this is an implementation issue I’m talking about the coding side , maybe what I’m suggesting is harder than recoding the layers
That’s call for a layer manager.
If somebody wants to do a global operation, or select some layers and change globally their settings, this should be done in a layer manager.
Of course, we are talking here of a ability that’s probably beyond the 2.5 scope. Maybe it would be possible to implement this in python and to get a nice layer manager script.
But first is first… Let’s just wait for the layer/group functionality be included in blender and then we can ask the devs the required functionality.
EDIT I’m so long winded I missed the last two posts writing this! /EDIT
Easy folks!
FIRSTLY I’d like to say that this is a very cool patch and I’d love to see it merged to trunk ASAP rather than postponed with lots of naval gazing until it becomes the “ultimate all things to all people” solution… It’s a step up from what we have now and would be immediately useful!
That said, the relationship between layers and groups needs careful consideration…
This is what I meant when i mentioned that there is a difference in other software between groups and layers… expecially when groups can be nested heirachically…
in photoshop the layers are a linear stack but groups become an organising principal…not the same thing and really really shouldn’t be…
given that farstahy’s group system is in the outliner you could have “heirarchys” of groups easily (for organisation NOT animation/parent child relationships)
Uncle entities mess of groups could be :
- blenrig character group:
+--->controls
+ --->arms
+ ---->hands and fingers
+---->legs
+---->torso
+---->untouchables
+----->skeleton
+---->dingo legs
+---->stretch arms
+----->driven muscles
+---->arms
+-----> pectorals
+-----> back
+bar set
+ hall
+----------do not export-------------
“IF” groups could be nested…
in such a complex case it’s likely you’d use the outliner for access anyway…
It does make a strong argument in my mind that “popping up” a blocking and modal outliner (think sticky keys) for fast assignment is a good thing…that’s what the “list” in uncle entities screengrab is after all, just “raw”… I’d forgo the bank of buttons on the header if there was a popup button or if it was accessible on a key shortcut (preferably both!)
the (other) point I’m trying to make is that groups and layers and heirarchies and sets are all organising principals that are subtly different…
Peoples choice is important as we will all work differntly on different sorts of projects
maybe this super group thing is throwing people of
basically think this … you click on a group and chose to convert it to a super group
which is basically another name for a layer and it is assigned that flag that will put it in top of the hierarchy and remove it from any other normal group and you can do the revers and convert a super group to a normal group and then you can nest it
so basically you are adding the missing layers functions to groups instead of the other way around plus you gain much more flexibility
Layers and groups are 2 different things,they HAVE to be different things.
Group are container for something,like character are in some program(maya),something like a super parent on top everything(into the group)
Layers are visibility and organization stuff,they have some colors to help visually,some properties(visibility(render and viewport),locking),nothing more.
Groups should owned only on 1 layer,it’s easy and clean.
Groups are a simple collection of object and should be only this.
To work well things have to be clean and easy.
My 2 cents
I’m typing in English i think …:spin:
you would still have the same groups all I’m suggesting is gust adding a special kind of groups that have layers properties call them layers if groups is giving you a hard time
besides these patch already broke that role you are talking about:eek:
You are a bit too much sarcastic.
I simply said how for me layers should work in general,having used different programs in my life(practically everything),I have my own taste in own it should work the feature,the patch is an occasion to talk about it(as everybody has started to do,but maybe I don’t have the right to do this).
No problem.and sorry for that.
But I’m against your idea(I think I can say this)
sorry i offended you
i gust thought that you didn’t get what i mean that’s all
sorry again
i think I’m not good at communicating with text
edit: come to think of it I’m not that good at normal conversation aether:confused:
This is more or less how I also think about layers and groups, esp layers. To me it seems what has been coded in this patch is more of group manager unless am confused and has little to do with layers but it provides more or less a workaround for somethings because at the moment we have 20 nameless boxes for layers.
i would love to get me hands on build and test this out, it sounds interesting so far, but if you are mucking about with groups and all how will this affect linking
Nice patch Farsthary.
I´ve spent a great deal in Maya myself and conceptually I think there are differences between what a group represent and what a layer represent. I don’t think it exclusively is an Idea that has its origin in 3D applications. In photoshop we use layers that contains pixel/vector data and some more and one can group these layers (containers) so they becomes a cluster of many layers.
A very useful function that I wouldn’t mind seeing in Blender is is global parameter grouping (layering) as seen in Houdini called “takes”.
http://www.sidefx.com/docs/houdini10.0/basics/takes
Good discussion, I remember seeing a layer discussion on the bf-committers mailing list but it was a while back and I cant find it right now. Anyway good initiative Farsthary.
OK, finally got around to reading the patch.
Looks like he just added the icons (and made them work) for renderability, etc in the outliner and that’s all. Anything else like list views or named layers on top of super groups controlling multi-functional hotkey magicfoo would probably take a lot of work to integrate into blender and from what I can tell this patch doesn’t even begin to go down that road.
Now if this patch were applied to 2.5 then it probably would be possible to come up with a ‘group manager’ using the python UI API that can do all sorts of cool stuff but for 2.4x this is just beating a dead horse. Might be able to do it without the patch by coding a button with something like;
for object in group
object.visibility('off')
but I’m not really sure.
Hi!
Thanks for the feedback and the disscussion 
I know is a tricky question Group vs Layers but here are what I think:
Groups are not layers BUT could have the layer features, groups are more flexible and powerfull than layers and the user should have the freedom to use them as layer or as other things if they want to.
I have checked the layer manager of other packages as well and the other things they have are coloring, and several flags for representation like bounding box, and excluding from several rendering parts. that are of secondary priority rigth now
If we use Groups as Layers the main difference will be that layers group objects in an exclusive way, and groups in a non exclusive way, but nothing stop you from grouping objects in an exclusive way :rolleyes:
The issue regarding overlapping groups is simple: with ONE toggling always set the child objects of the active group to the same state of it, that way toggling TWO TIMES you can ensure there´s no hidden object that belong to other group and also that every object in that group has the state that you want.
I don´t know if some build has being made but seen that in work could fade some concerns.(I could not upload my build) I don´t see why that group manager could not replace a layer manager, they DO the same, whether easier or not is something that could be changed on the march, and on top of that agroup manager offer you the freedom to make overlapping and nested groups something that is unthinkable for layers but as stated before, one use case of it could be that “Superset” layer:
you have one layer_group for bolts and one for nuts, and you have a superset of bolts and nuts, that way toggling two times you could show/hide all bolst and nuts in your scene.
Off course, more things could be added, like state inversion and other minor features, and also I need to investigate the interaction with other parts of Blender like the current render layers if the aim is to implement the the 20 blender layers functionality, but for now is just a complement of the 20 layers for big set ups.
Currently I could not commit that myself and also need the review and the approval of other devs, so is not in my hands to integrate it, I just code it to attract the interest of some dev to integrate it.
I have to metion that although is not finished, that patch is pretty functional and usefull 
Cheers to all Farsthary
Like Uncle entity says, is a very simple patch, it just in the outliner add the flaggs buttons for every groups that previously only where aviable for individual objects and trigger the code for changing the state of every child object of the active group, it dont represent a trauma in Blender code and the rest of the functionality is provided in the Outliner itself, it has nothing to do with the patch (though if very necesary could be added).
If the group list is to big simply scroll down in the outliner :eek:, I don´t understand the concern on it.
It is just a natural extension to the group functionality, nothing more nothing less, in fact I couldn´t belive that someone hasn´t code that before :eek:.
Yeah, was thinking the same thing when I looked at your patch…simple yet incredibly useful feature.
First of all, the term “layer” in 3d is a misnomer. Layer connotes something that sits on top of something, like another layer. The name is more appropriate on 2d apps. In 3d they could have used a more appropriate term like a container or something.
Any means that let you separate or group objects in some kind of containers with an unlimited amount of number, toggle visibility and assign names is way better than the current layer system in Blender.
I was just about to point that out as well. Whatever its called the fact remains that the important part is the organizing of data. Farsthary decided to do it in the outliner and use groups as opposed to creating a “traditional” layer manager that you would find in other apps but like you said these aren’t really layer managers.
One thing that would be cool i if we can do things like in XSI where you can define different layers that correspond with renderlayers so you can have a group that has materials relevant to saya material pass etc, all affecting the same object. I forgot what XSI calls these at the moment but they differentiate between layers the way they are used in other apps and layers used to organize for rendering purposes only. In-fact what Farthary has done here reminds me a bit of what XSI does with the scene explorer.
Thank you very much farsthary for such elegant solution.