[Bf-animsys] NLA System SoC - 'Phase 1' more or less complete

Sat Jun 13 22:19:19 CEST 2009

> As far as I understand, your idea of these "f-curve bags" falls goes a bit
> like:

   I'm open to trying other workflows too.  What's more important to
me is simply that "f-curve bags" exist as a first-class citizen of the
system.  We can continue to play with different workflows down the
road without breaking backwards/forwards compatibility as long as the
core system supports the kinds of structures we want (i.e. the
difference between tools and data).
   The reason that scene-linked actions appeal to me so strongly is
simply that they provide "f-curve bag" functionality really well, and
in a way that the system is already designed to handle (at least that
was my impression).

> Now, these scene actions can get directly used in NLA-mixing via the Scene's
> AnimData, just like what we see now on Objects. Heck, you could do that for
> shapekeys, materials, etc. if you really wanted/needed to, but that's beside
> the point. The point is that, although by default we only see this on
> object-level, it could work at any level you like. The system doesn't care,
> as long as everything in some Animation Data block can be evaluated using
> the ID-pointer (that the Animation Data is attached to) as the base for the
> paths used.

   Maybe I'm misunderstanding something.  But how would you mix, say,
a scene-level action with an object-level action in the NLA editor?
Say they overlap in what data they affect.  Right now they are
strictly segregated in the NLA editor, with no way to arrange them
vertically because they're stuck in their own hierarchy.  How does a
user specify the mixing between the two?

> Sometimes, this might be some group instantiater
> instead (with references going through the group).

   Group-level actions?  That would be *awesome* for rigging.

> Firstly, as long as the above criteria are followed, there are no
> problems. Therefore, an F-Curve bag is simply any Action that fullfills the
> above criteria.

   Right.  Scene-level action = f-curve bag.  That makes sense to me.

> However, for some reason or other, we might find that we need to split these
> up.  A simple tool can be used to do this,

   Yes, I'm all for this.  Tools for splitting, merging, and
"rebasing" (i.e. re-link a scene-level action to an object, or
vice-versa, with paths changed appropriately) would be great.
   IMO, especially if we have a nice rebasing tool then the particular
default we choose (scene-level, object-level, whatever-level actions)
isn't so important, because the user can easily move between them as
needed.  Then the default just becomes a matter of what is the most
common use-case, and how does it impact workflow in other ways.

--Nathan V

> When everything gets keyframed, the keyframes get added to an active action
> on the Scene level. You could also choose to separate out (using some tool
> that is at this stage theoretrical) some of the F-Curves in this action to
> be able to be used directly on individual datablocks...
>
> --
>
> Now, these scene actions can get directly used in NLA-mixing via the Scene's
> AnimData, just like what we see now on Objects. Heck, you could do that for
> shapekeys, materials, etc. if you really wanted/needed to, but that's beside
> the point. The point is that, although by default we only see this on
> object-level, it could work at any level you like. The system doesn't care,
> as long as everything in some Animation Data block can be evaluated using
> the ID-pointer (that the Animation Data is attached to) as the base for the
> paths used. In other words, as long as two said properties are attached to
> some common ancestor/user, it's perfectly ok to have them in the same action
> as long as that action is attached to the common ancestor and not to any one
> of them.
>
> So, for our commonly used case of animating multiple objects, the most
> obvious solution is to use the scene level. Sometimes, this might be some
> group instantiater instead (with references going through the group).
>
> The second issue we have then is about "F-Curve Bags" should work and/or be
> created. Firstly, as long as the above criteria are followed, there are no
> problems. Therefore, an F-Curve bag is simply any Action that fullfills the
> above criteria.
>
> However, for some reason or other, we might find that we need to split these
> up. A simple tool can be used to do this, copying or moving selected
> F-Curves to another action and/or optionally reconfiguring paths if the new
> action is to be used in a more restricted context (i.e. one object instead
> of multiple objects through scene). This could be used to isolate curves to
> be used on specific objects/AnimData blocks. However, another purpose could
> be to split up some Scene-based Action to allow it to be mixed with other
> Scene NLA-strips with more control over the final result.
>
> So I guess I'm not as opposed to this idea now I as was a few weeks/months
> ago, though I'm still not too keen on certain approaches. :)
>
>
> Joshua
>
> On Thu, Jun 11, 2009 at 5:12 PM, Nathan Vegdahl <nathanvegdahl at gmail.com>
> wrote:
>>
>> I hate to sound like a broken record, but after playing with the NLA
>> branch for while now, I have one primary question:
>>   How are "IPO bags" (or rather f-curve bags) going to fit into this
>> workflow?  As the interface stands now (where the tracks are organized
>> by object) I struggle to think of a sane/natural way to incorporate
>> such functionality.  That doesn't mean there *isn't* a sane/natural
>> way, just that I can't think of one.
>>
>>   For what I personally expect to use the NLA system for, the
>> "f-curve bag" functionality is important to several primary use-cases.
>>  I'm a little concerned that perhaps it's being brushed off as
>> something that can be worked out as an after thought.  But I fear that
>> when we actually get around to putting it in that the workflow
>> developed by then will be highly ill-suited to it.
>>
>>   I would, personally, feel a lot more comfortable if we could figure
>> out before-hand how "f-curve bags" will fit into all of this, prior to
>> Aligorith doing too much work on this workflow to go back and make any
>> necessary changes (which might be substantial?).
>>
>> --Nathan V
>>
>> On Tue, Jun 9, 2009 at 9:44 PM, Joshua Leung<aligorith at gmail.com> wrote:
>> > Hi all,
>> >
>> > I figured that I should just leave a little note here about the current
>> > status of the NLA SoC progress. As of the time of writing, I consider
>> > phase
>> > 1 of this project 'complete'.
>> >
>> > What was phase 1 again?
>> > - Implementation of the workflow + broad outline of the NLA system as
>> > described
>> > http://wiki.blender.org/index.php/User:Aligorith/SummerOfCode2009
>> > (basically the same as the doc I posted a few weeks ago).
>> > - Implementation of most (actually, just enough of the core stuff) of
>> > the
>> > backend code to evaluate NLA, including IO-code for new system,
>> > RNA-wrapping...
>> > - Implementation of enough basic tools for the basic NLA design to be
>> > tested
>> >
>> > <--- We are here... it's a good point now to try and animate a few shots
>> > and
>> > get a feel for what's working (I hope that is most if not all of it :) /
>> > not-working >:( --->
>> >
>> > Phase 2 involves:
>> > - Version patching code
>> > - Finishing off some of the more complicated evaluation matters (mostly
>> > new
>> > stuff) - F-Curve controls for influence + time, transitions,
>> > threadsafety
>> > for evaluating values that only occur in some strips
>> > - Long overdue code cleanup work on some things I quickly threw together
>> > in
>> > places
>> > - Implementing tools which make NLA use more fun + more efficient
>> >
>> > Phase 3?
>> > - Foundations for auto-walker stuff... if I get some time, I might even
>> > code
>> > one if there's sufficient interest :)
>> >
>> >
>> > A cool piece of trivia I should mention at this stage is that the NLA
>> > system
>> > is about as functional as the trunk version :)  That is, in terms of
>> > tools
>> > implemented, it's just about the same (there are 2-3 tools I know of
>> > which I
>> > haven't implemented yet, though there are ways around that). In terms of
>> > evaluation code, there are many things the new system has that the old
>> > doesn't (not considering the stuff we've decided to cull or move
>> > elsewhere).
>> >
>> > Laters,
>> > Joshua
>> >
>> > _______________________________________________
>> > Bf-animsys mailing list
>> > Bf-animsys at blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-animsys
>> >
>> >
>> _______________________________________________
>> Bf-animsys mailing list
>> Bf-animsys at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-animsys
>
>
> _______________________________________________
> Bf-animsys mailing list
> Bf-animsys at blender.org
> http://lists.blender.org/mailman/listinfo/bf-animsys
>
>