[Bf-committers] Naming layer
Alexander Ewering
blender at instinctive.de
Wed Apr 20 14:03:42 CEST 2005
Ton,
you knew that you would get some annoying feedback on this issue, right? :)
On Wed, 20 Apr 2005, Ton Roosendaal wrote:
> Hi,
>
> The Blender layer system uses bitmasks, meaning there is no single layer you
> can use to give it a name. If we like it or not, but it's being used (and
Well, the *layers* as seperate entities do indeed exist. It's just that there
is the occasional (rare) possibility of objects belonging to several layers
at once. But the layers can indeed have names - there are exactly 20 of them,
and each can have its properties.
> useful) to define relationships between objects, like metaballs or do define
> which lamps give lights on what objects (lamp in layer 1,2,3, object in layer
> 3, scene showing layer 2+3).
Yes, instinctive's layer manager is, among others, used for exactly that. It's
used for determining what objects should be locked, what objects should be
visible when, what objects belong to which *named* 'group' (Layer), etc.
> As for the instinctive layer manager; this implementation looks like the
> usual quick & easy hack, something probably Alexander can use perfectly, but
> not something that complies to a standard as I like to see it for Blender. A
It's OK to have high standards, no doubt.
> good system to manage relations/grouping or properties for your Objects in a
> Scene will be just more work, requiring in-depth understanding of the full
> range of Blender, a maximum integration level, also related to extending the
Trust me, I have total understanding of the full impact of the Layer system,
scenes, views, non-locked views, local views, etc., and as the past has
shown, more so than the majority of other Blender users.
> Sometimes I can seem like a show-stopping bitchy conservative here... :) I
I like conservative people, I'm one myself. My second name is Ratzinger ;-)
> realize we need to find good ways to attract & involve new developers. But
> the times are also over to accept each code contribution only because it's a
> desired feature. We only run into troubles with that.
> Don't forget that the parts that nicely work within a Blender architecture
> are the real strong aspects in Blender, working already for 10 years, and
> still future proof. This stability allows for quick hacks, which is OK for
> within a production environment (like instinctive blender), but not per
> definition fit for inclusion in official releases.
You make an interesting point here, and it's what I've been saying for the
past years (Now, you will hate me even more!):
Blender *used* to be a production tool (in NeoGeo times), and you know
best yourself that it was (and is) FULL of quick hacks.
What I find funny is that since it has gone open-source, the Foundation seems
to be aiming at creating a typical, marketable end-user tool for the masses
(BF-Blender) opposed to a "thing that gets the job done" (like NaN Blender).
But this is probably unavoidable... Every company has its own priorities and
special uses - so instinctive-blender and its special functionality is OK for
*one* company... BF-Blender has the difficult task to please *everyone* - maybe
it's insane to set yourself such a high goal.
| alexander ewering instinctive mediaworks
| ae[@]instinctive[.]de http://www[.]instinctive[.]de
More information about the Bf-committers
mailing list