<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Joshua,<div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div><br></div><div>-William</div><div><br></div><div><br></div><div><br><div><div>On 11 Jun, 2009, at 1:42 PM, Joshua Leung wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Nathan,<br><br>As far as I understand, your idea of these "f-curve bags" falls goes a bit like:<br>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...<br> <br>--<br><br>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. <br> <br>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).<br> <br>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. <br> <br>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. <br> <br>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. :)<br><br><br>Joshua<br><br><div class="gmail_quote">On Thu, Jun 11, 2009 at 5:12 PM, Nathan Vegdahl <span dir="ltr"><<a href="mailto:nathanvegdahl@gmail.com" target="_blank">nathanvegdahl@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I hate to sound like a broken record, but after playing with the NLA<br> branch for while now, I have one primary question:<br> How are "IPO bags" (or rather f-curve bags) going to fit into this<br> workflow? As the interface stands now (where the tracks are organized<br> by object) I struggle to think of a sane/natural way to incorporate<br> such functionality. That doesn't mean there *isn't* a sane/natural<br> way, just that I can't think of one.<br> <br> For what I personally expect to use the NLA system for, the<br> "f-curve bag" functionality is important to several primary use-cases.<br> I'm a little concerned that perhaps it's being brushed off as<br> something that can be worked out as an after thought. But I fear that<br> when we actually get around to putting it in that the workflow<br> developed by then will be highly ill-suited to it.<br> <br> I would, personally, feel a lot more comfortable if we could figure<br> out before-hand how "f-curve bags" will fit into all of this, prior to<br> Aligorith doing too much work on this workflow to go back and make any<br> necessary changes (which might be substantial?).<br> <div><br> --Nathan V<br> <br> On Tue, Jun 9, 2009 at 9:44 PM, Joshua Leung<<a href="mailto:aligorith@gmail.com" target="_blank">aligorith@gmail.com</a>> wrote:<br> </div><div><div></div><div>> Hi all,<br> ><br> > I figured that I should just leave a little note here about the current<br> > status of the NLA SoC progress. As of the time of writing, I consider phase<br> > 1 of this project 'complete'.<br> ><br> > What was phase 1 again?<br> > - Implementation of the workflow + broad outline of the NLA system as<br> > described <a href="http://wiki.blender.org/index.php/User:Aligorith/SummerOfCode2009" target="_blank">http://wiki.blender.org/index.php/User:Aligorith/SummerOfCode2009</a><br> > (basically the same as the doc I posted a few weeks ago).<br> > - Implementation of most (actually, just enough of the core stuff) of the<br> > backend code to evaluate NLA, including IO-code for new system,<br> > RNA-wrapping...<br> > - Implementation of enough basic tools for the basic NLA design to be tested<br> ><br> > <--- We are here... it's a good point now to try and animate a few shots and<br> > get a feel for what's working (I hope that is most if not all of it :) /<br> > not-working >:( ---><br> ><br> > Phase 2 involves:<br> > - Version patching code<br> > - Finishing off some of the more complicated evaluation matters (mostly new<br> > stuff) - F-Curve controls for influence + time, transitions, threadsafety<br> > for evaluating values that only occur in some strips<br> > - Long overdue code cleanup work on some things I quickly threw together in<br> > places<br> > - Implementing tools which make NLA use more fun + more efficient<br> ><br> > Phase 3?<br> > - Foundations for auto-walker stuff... if I get some time, I might even code<br> > one if there's sufficient interest :)<br> ><br> ><br> > A cool piece of trivia I should mention at this stage is that the NLA system<br> > is about as functional as the trunk version :) That is, in terms of tools<br> > implemented, it's just about the same (there are 2-3 tools I know of which I<br> > haven't implemented yet, though there are ways around that). In terms of<br> > evaluation code, there are many things the new system has that the old<br> > doesn't (not considering the stuff we've decided to cull or move elsewhere).<br> ><br> > Laters,<br> > Joshua<br> ><br> </div></div><div><div></div><div>> _______________________________________________<br> > Bf-animsys mailing list<br> > <a href="mailto:Bf-animsys@blender.org" target="_blank">Bf-animsys@blender.org</a><br> > <a href="http://lists.blender.org/mailman/listinfo/bf-animsys" target="_blank">http://lists.blender.org/mailman/listinfo/bf-animsys</a><br> ><br> ><br> _______________________________________________<br> Bf-animsys mailing list<br> <a href="mailto:Bf-animsys@blender.org" target="_blank">Bf-animsys@blender.org</a><br> <a href="http://lists.blender.org/mailman/listinfo/bf-animsys" target="_blank">http://lists.blender.org/mailman/listinfo/bf-animsys</a><br> </div></div></blockquote></div><br> _______________________________________________<br>Bf-animsys mailing list<br><a href="mailto:Bf-animsys@blender.org">Bf-animsys@blender.org</a><br>http://lists.blender.org/mailman/listinfo/bf-animsys<br></blockquote></div><br></div></body></html>