[Bf-committers] Layer system

GSR gsr.b3d at infernal-iceberg.com
Sat Dec 22 18:02:58 CET 2007


Hi,
matt at mke3.net (2007-12-22 at 1629.33 +1100):
> On 22/12/2007, at 2:18 PM, Stephen Swaney wrote:
> > On Sat, Dec 22, 2007 at 01:38:47PM +1100, Matt Ebb wrote:
> >> Erm, no, an object can most definitely be in more than one group.
> > If you can put objects in muliple groups and you can put groups in
> > layers, then you essentially have an infinite number of layers  and
> > still have the simplicity of the current layer system as a top level  
> > of
> > organization..
> No you don't, not at all, though being able to use the visibility/ 
> renderability flags for groups would go a long way to help this.

I read what he said as "we can get the features required by means of
current groups", and in that sense, then you do get infinite "layers",
you get as many as different names you can use. So "not at all" is not
exactly right either. Currently b-groups are not a full organization
system, but can become so with some polish and extra things, and then
(mostly) leave alone b-layers as they are.
 
> I think a lot of people commenting here don't see the limitations in  
> Blender's ancient layer system because for simple things, Blender  
> works just fine. Even to the extent of doing one task (i.e. modelling  
> or animation only) the system holds up ok, but as soon as you start  
> doing things that are more complex, in a production environment where  
> you need to manage the files containing all sorts of models,  
> animation, lights, render settings, the whole things gets so caught up  
> in spaghetti complexity, that it's a real pain.

I know the system is limited. Thus I am opposed to bolt on more hacks
onto b-layers.

> One thing that really doesn't help the situation is that layers in  
> Blender are (ab)used for all sorts of only slightly related things. As  
> a method of organisation, a simplistic one-size-fits-all approach  
> breaks down when there are multiple things you want to organise for  
> different tasks.

And patching up the layer system is not going to get Blender out of
the problem, but make the hole deeper. Completing and extending
groups, or maybe another thing, will. But that requires thinking
first, coding later. As things have gone, the commitment sounds more
on just hacking Blender layers like if this time the patch was the
right one. Some of the past ones were the right ones, they just
extended the idea behind the system without compromising it (names?
colours? disallow selection?  force draw modes? those things do not
change the playground too much, we already got things like "select all
by layer" in a menu).
 
[...] 
> Anyway, I'm not sure if I have any real answers, though the whole  
> problem is a lot more complex of whether to use bitflags or linked  
> lists. Two things would probably help a lot:
> * Adding the toggles for view/select/render to groups
> * Adding an option for lamps to limit their effect to a certain group,  
> like the layer option.

Other items worth considering:

* Add some flexibility to Render Sets (see next) so you can choose
  layers (this has to be there for back compatibility) and or groups
  as part of a Set (TBD: figure if there should be "and" or "or", and
  how to handle that in interface and code).

* Rename Render Layers as Render Sets (= stop the naming abuse) or
  some other new name.

* Document the 20 buttons in Groups interface (tooltips say nothing).

* Make OOPS completly editable, so Groups (among other things) can be
  created there.

* Make Outliner more editable, same reason than OOPS.

And probably more things. Now is the time to figure the things and
develop the concepts. Then as time allows, they can be implemented.

GSR
 


More information about the Bf-committers mailing list