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

[William Reynish]

Hi Joshua,

This outline sounds quite nice. As you say, scene-level actions (or 'F- 
Curve bags') can contain an arbitrary number of F-Curves. That means  
that an action can encompass one object, one ID block or the entire  
scene. But the action itself doesn't belong to anything.

Any animation that is performed by the user simply goes into the  
current action. Blender can start you off with a 'default' action that  
everything goes into. As you say, for it to be flexible, you'd need to  
be able to separate out certain F-Curves, much like separating polys  
into several meshes.

On a more technical note, the real challenge I suppose is how the  
system references the data. What happens if you animate a material,  
but then replace that material? Does the animation the carry over to  
the new one? I'm not sure what's best here, but the old system of just  
using bone names seems a little simplistic, especially now that  
actions are about much more than just bones ;) Hmm, perhaps this isn't  
an issue, not sure.

Cheers,

-William



On 11 Jun, 2009, at 1:42 PM, Joshua Leung wrote:

> Nathan,
>
> As far as I understand, your idea of these "f-curve bags" falls goes  
> a bit like:
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-animsys/attachments/20090611/e31b0250/attachment.html>