Hi Nathan, Bassam, etc etc. To prevent this topic to get lost in the avalanches of emails here, let's consider to re-activate the bf-animsys list for it.
http://lists.blender.org/mailman/listinfo/bf-animsys That way things get a bit more condensed and coherent. I'll make sure that the devs who will do animation coding for Gooseberry will report on that list and use it to validate their todo lists, planning and designs. Might take a month or two - we have to do a fundraiser first still :) Laters, -Ton- -------------------------------------------------------- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands On 14 Feb, 2014, at 2:32, Nathan Vegdahl wrote: >> +1 -though maybe 'proxy' itself doesn't need to remain, just a way of >> overriding in a more generic way > > Agreed. As useful as the proxy system has been, it's really time to > put it to rest in favor of something much more flexible, robust, and > generic. > >> I'm thinking 'more like the way' python overriding works, but in the UI >> instead: I guess that's what you mean by 'RNA layering system' below. > > Yes, that's what I meant. :-) I also think it's important to plan for > even more flexibility than that. An 'RNA layering system' would be > the foundation, and provide some nice basic guarantees about things > you can do override locally. But ultimately we also want to support > things like locally added/overridden shape keys, vertex groups, > modifiers, materials, physics... the list goes on. > > But even just basic RNA value overriding would be a good start. > > And it doesn't have to be an all-at-once kind of thing. It can be a > migratory kind of thing. E.g. the proxy system can still be > maintained in parallel until things actually get to the point where > it's fully redundant. > > In any case, I just wanted to get the conversation started, because > this is one of those un-sexy problems that's easy to overlook and > ignore because it's not fun. But it desperately needs to be addressed > at some point (I'm hoping sooner rather than later). > > --Nathan > > > On Thu, Feb 13, 2014 at 10:59 AM, Bassam Kurdali <bas...@urchn.org> wrote: >> On Thu, 2014-02-13 at 09:48 -0800, Nathan Vegdahl wrote: >>> Regarding the Gooseberry meeting: >>> >>> Is this a good time to finally revisit the proxy system as well? I.e. >>> making it useful for all object types and data, not just Armatures. >>> And ridding it of the weird and obscure quirks it currently has. I >>> could be wrong, but that seems like one of the biggest production >>> bottlenecks that Blender currently faces. It certainly made a lot of >>> things painful on Sintel. >> +1 -though maybe 'proxy' itself doesn't need to remain, just a way of >> overriding in a more generic way - I guess it could be called proxy, but >> I'm thinking 'more like the way' python overriding works, but in the UI >> instead: I guess that's what you mean by 'RNA layering system' below. >>> >>> We had discussed at the time changing it to some kind of "RNA >>> layering" system, where linked data could have its RNA values locally >>> overridden. We were essentially doing that on Sintel for simulation >>> anyway, just via Python scripts. But it was a terrible user >>> experience, error prone, and impractical for doing any kind of complex >>> animation since it had to be scripted. >> We have been making custom scripts with UIs in wires for empathy for the >> same thing: basically creating local scene properties and a toolbox >> interface, to override specific linked properties. It is pretty solid, >> but, you do have to plan ahead for every single override, creating a >> bottleneck on scripters/riggers to make things available. It also is >> cumbersome from an animation perspective (you would have to do on frame >> change update handlers for any properties you need animated) - but the >> fact that this stuff can be kludged via python is encouraging that it >> might be implementable as a 'proper' design. >>> >>> --Nathan >>> >>> On Sun, Feb 9, 2014 at 8:25 AM, Ton Roosendaal <t...@blender.org> wrote: >>>> Hi all, >>>> >>>> Here are the notes from today's meeting in irc.freenode.net #blendercoders. >>>> >>>> 1) Work on upcoming 2.70 release >>>> >>>> - Planning for release didn't change: >>>> http://wiki.blender.org/index.php/Dev:Doc/Projects >>>> >>>> - Image Editor panels are being reshuffled now: >>>> https://developer.blender.org/T38371 >>>> >>>> - Crucial bugs to be done are now listed in a special page: >>>> https://developer.blender.org/project/view/35/ >>>> >>>> - Showstopper bug is for Windows with non-Ascii character file paths (like >>>> Japanese). >>>> https://developer.blender.org/T35176 >>>> Campbell Barton and Tamito Kajiyama will check on it. >>>> >>>> - Note! Python scripters who added toolbar buttons should check and/or >>>> update scripts, because of news tabs there. Connect Campbell if you need >>>> help. >>>> >>>> - Sketchfab will submit an add-on to be included in release, using the >>>> 'commercial services' deal we've reviewed and accepted last August. It >>>> still needs to be reviewed though. >>>> >>>> 2) Other projects >>>> >>>> - Ton Roosendaal wrote a report of the developer meeting in Blender >>>> Institute, to map out issues for the next film project: >>>> http://gooseberry.blender.org/developer-meeting-pipeline-and-tools/ >>>> >>>> - Lukas Toenne started to work on a cleanup compositor code, will be >>>> online this week. >>>> >>>> - After the meeting, there was a discussion on the status of NPR render in >>>> Blender, and the 'BEER' project from Bong Wee Kwong. >>>> http://wiki.blender.org/index.php/User:LightBWK >>>> >>>> A new mailing list has been added to discuss work on Blender's NPR render >>>> future: >>>> http://lists.blender.org/mailman/listinfo/bf-blender-npr >>>> >>>> Thanks, >>>> >>>> -Ton- >>>> >>>> -------------------------------------------------------- >>>> Ton Roosendaal - t...@blender.org - www.blender.org >>>> Chairman Blender Foundation - Producer Blender Institute >>>> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands >>>> >>>> >>>> >>>> _______________________________________________ >>>> Bf-committers mailing list >>>> Bf-committers@blender.org >>>> http://lists.blender.org/mailman/listinfo/bf-committers >>> _______________________________________________ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >> >> >> _______________________________________________ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers