[Bf-animsys] Library Linking and Proxy System reboot

[Nathan Vegdahl]

> but I thought this was already a gooseberry target?

If it is, I haven't seen it mentioned in any of the blog posts.
Unless it's just assumed to be part of the "asset manager" target.

But either way, I'd like it to be a specific target of its own, rather
than vaguely part of some category that includes e.g. cloud tools.
It's too easy for it to get lost or forgotten as a target that way.

--Nathan

On Thu, Jun 5, 2014 at 11:37 PM, Bassam Kurdali <bassam at urchn.org> wrote:
> +400000
> but I thought this was already a gooseberry target?
> On Thu, 2014-06-05 at 17:05 -0700, Nathan Vegdahl wrote:
>> Back in February I broached the topic of improving the library linking
>> system as part of the Gooseberry technical targets:
>> http://lists.blender.org/pipermail/bf-committers/2014-February/042812.html
>>
>> I'd like to continue that discussion here on the bf-animsys mailing
>> list, as suggested by Ton.
>>
>> A quick summary:
>> The core problem is that you cannot locally animate or otherwise
>> modify library-linked data in your scene.  Currently Blender has a
>> "proxy" system that works around this limitation for armatures, but it
>> has a lot of weird quirks and is limited to armatures.  This is a
>> severe limitation and production workflow problem for Blender.
>>
>> My current tentative proposal is outlined in the link above, and is
>> further clarified in these links:
>> http://lists.blender.org/pipermail/bf-committers/2014-February/042814.html
>> http://lists.blender.org/pipermail/bf-committers/2014-February/042822.html
>>
>> I think this is an extremely important topic that has been repeatedly
>> overlooked over the past few years because:
>>
>> 1. It really only becomes a major issue in complex productions, of
>> which there are (currently) few done in Blender.  Therefore most
>> Blender users (and many developers) have difficulty seeing why it's
>> such a horrible situation.
>>
>> 2. We have hacky workarounds that are "good enough" to make excuses
>> and push it down as lower-priority than other development goals.
>>
>> 3. It's an "unsexy" problem that doesn't strictly change what Blender
>> can produce, it only improves workflow.
>>
>> But really, this is a serious issue that significantly hinders
>> efficient, scalable, and intuitive workflows in Blender productions.
>> And I admit that am disappointed that it doesn't appear to be a
>> specific technical target for Gooseberry, which as far as I know is
>> largely about improving production workflow in Blender.  (Unless I
>> missed it? http://gooseberry.blender.org/may-developer-meetings/)
>>
>> Can we please add this as a specific technical target for Gooseberry?
>> And let's further discuss design and how we can go about this.
>>
>> Thanks!
>>
>> --Nathan
>
>