[Bf-animsys] NLA System SoC - 'Phase 1' more or less complete
aligorith at gmail.com
Thu Jun 11 13:42:09 CEST 2009
As far as I understand, your idea of these "f-curve bags" falls goes a bit
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
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
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. :)
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
> > 1 of this project 'complete'.
> > What was phase 1 again?
> > - Implementation of the workflow + broad outline of the NLA system as
> > described
> > (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
> > <--- We are here... it's a good point now to try and animate a few shots
> > 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
> > 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
> > 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
> > one if there's sufficient interest :)
> > A cool piece of trivia I should mention at this stage is that the NLA
> > is about as functional as the trunk version :) That is, in terms of
> > 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bf-animsys