[Bf-committers] Animation editor context

Joshua Leung aligorith at gmail.com
Wed Apr 11 02:41:26 CEST 2012


Hi Lukas,

[Warning, this may be a long email...]

On Tue, Apr 10, 2012 at 8:49 PM, Lukas Tönne
<lukas.toenne at googlemail.com> wrote:
> Currently the animation editor does not support node groups. This is
> because the animation editor filters any possible channel set based on
> the active context, i.e. mostly scene, world and the active object.
> This works fine for any data block that is uniquely associated to an
> object (i.e. you can get from object to ID block anim data
> unambiguously). Correct me if i'm wrong here, since i don't have a
> whole lot of animation experience :)
>
By and large this is correct. The issue of what to do with what I'll
call "transient" ID-blocks (i.e. textures and nodegroups) is
problematic, since they can be used in multiple places, with those
places tending to be quite deeply nested.

One of the ideas for solving this that I've mooted in the past is just
dumping a list of all of those which currently have at least one user
at the bottom of the list (after scene stuff). While this may not work
that great when dealing with multiple scenes, for most nodegroups,
this will probably be sufficient.


On Tue, Apr 10, 2012 at 8:49 PM, Lukas Tönne
<lukas.toenne at googlemail.com> wrote:
> One possible solution could be to base the display of node animation
> data on the visible node editors, rather than the active object.
> ... snip ...
> Does this sound like a reasonable idea? Or are there design problems
> i'm overlooking?

There are perhaps two aspects to why this sort of thing isn't done in Blender:

* Conceptual/Design Principles
AFAIK, the original idea behind Blender's "Editors" (i.e. Screen Areas
such as 3D View, DopeSheet, etc.) was that they were to act as
separate applications (or at the very least, standalone views) which
just happen to have access to the same underlying database. IIRC, I
might have heard Ton once say that there was once an idea during the
early days to be able to have external things like calculators etc.
running in separate editors.

Anyways, the key principle governing this is that, apart from the
global database, an editor only knows about its own data. That is, it
shouldn't assume that any other editors exist, and definitely
shouldn't try to fiddle with or use what may be present in any other
editors (as those things are private to those). Admittedly, we do have
one or two examples of things that try to deviate from this, but I
think we'll all agree that they are somewhat hairy in places and have
been problematic spots in the past.

By and large, this is what's been governing my design/implementation
decisions when dealing with various issues.

* Technical Considerations
One of the technical barriers is that there is no way to reliably
refer to any particular editor instance within a screen layout (NOTE:
this is similar to how we generally only refer to ID-blocks only, and
not entities within them, with the exception being when we use the ID
+ a named identifier), and to have one which accurately matches up to
what the user actually expected. Sure, we can just grab the first one
of a certain type, or perhaps the largest. But, things like grabbing
the largest aren't exactly the best strategy - we may have the
"dependent" editor maximised so this falls down, and even if nothing
is maximised, finding the largest area actually doesn't always end up
targetting what you'd intuitively think (anyone remember
render-in-largest-area?).

One of the complications leading into this is that there may be more
than one editor of a particular type open at a time. Another is that,
since 2.5 we can now have more than one window open. From what I've
seen from the Open Movie Projects, it is common practice to dump the
animation editors on the secondary monitor, and have the main
view/editor on the primary. In this case, we actually have two
separate screen layouts (out of quite a few), which may slightly
complicate matters.

Though on second thought, these problems are not intractable... just
not dead straightforward to get working, and which may be troublesome
to get bugfree.

* Other considerations
Now, as Daniel pointed out, it is very useful for animators to be able
to retime everything in the scene while seeing how various parts fit
in with each other.


So overall, it's possible that there may be a place for this sort of
dedicated filtering, and indeed it might be useful for those who deal
with nodes all day long. However, I think we should only take this
step if every other alternative fails first.


Regards,
Joshua


More information about the Bf-committers mailing list