[Bf-animsys] Library Linking and Proxy System reboot

Jeffrey H italic.rendezvous at gmail.com
Sat Jun 7 07:08:38 CEST 2014


I am in favor of this proposal. There have been a number of times that I
want to edit rigs or mesh, but it's hard to do without going back into the
source file, which is pretty bad for pipeline when it's on a per-shot basis
(even if it's just one or two test animation files). I remember someone
mentioning the proxy system when discussing targets, but I don't think it
was officially written down. Regardless, it would be great if this system
got the attention it needs.


On Fri, Jun 6, 2014 at 7:06 AM, Nathan Vegdahl <nathanvegdahl at gmail.com>
wrote:

> > 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
> >
> >
> _______________________________________________
> Bf-animsys mailing list
> Bf-animsys at blender.org
> http://lists.blender.org/mailman/listinfo/bf-animsys
>



-- 
Jeffrey "Italic_" Hoover
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-animsys/attachments/20140606/48a74cd9/attachment.html>


More information about the Bf-animsys mailing list