[Bf-committers] Layer system
aceone at bellsouth.net
Sat Dec 22 06:51:22 CET 2007
One of the few that understands.Thanks.
----- Original Message -----
From: "Matt Ebb" <matt at mke3.net>
To: "bf-blender developers" <bf-committers at blender.org>
Sent: Saturday, December 22, 2007 12:29 AM
Subject: Re: [Bf-committers] Layer system
> 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
> 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 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.
> 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.
> For example, layers are used for;
> * Hiding and showing models, for example to hide unwanted 'trash'
> stuff, or to use temporarily to hide high-poly objects to speed up
> interactive display, or to hide away helper objects like armatures or
> curve guides or force fields that may be getting in the way
> * Defining render layers, determining what objects will appear in
> different image buffers in the compositor upon rendering.
> * Defining what lamps will affect what geometry ('layer' option)
> * Controlling the effect of particle systems/deflectors (this one is
> utterly ridiculous, force fields will only affect particles systems on
> the same layer, which swiftly ruins your organisation of different
> systems/helpers, especially if you have multiple systems sharing force
> * And probably one or two other things I've forgotten too.
> The trouble with this, is that these tasks often have logically
> nothing to do with each other at all, and so the usage conflicts.
> Defining objects that you want as a render pass image generally has
> nothing to do with how you want to organise your scene to disable high
> poly geometry in the view, but you're force to use the same system for
> it all. It's like using the Dewey decimal system to organise both your
> books and the species of the animal kingdom.
> Currently the way to work around this mess is to split your object
> layers up even more finely grained and do stupid tricks like putting
> objects on multiple layers, not because it makes more sense to
> organise it that way, but because you have to work around the system
> to make it happy, and end up with something that's barely organised at
> all. And of course doing all this stuff just uses more and more of the
> hugely limiting number of 20 layers, which I run up against quite often.
> Especially doing things like that when you have all sorts of
> convoluted links and objects on multiple layers, it's very easy to
> make mistakes and get lost in it all. It's very easy to forget that an
> object is on multiple layers, and it can get cleared so easily with a
> simple stroke of a muscle-memorised M->number key->Enter. And then you
> find out after rendering for a few hours that you moved a particle
> deflector to the wrong layer by accident while trying to work around
> it all, and you have to re-render the shot again. It's all very
> 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.
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers