<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style>
<!--
@font-face
        {font-family:Calibri}
@font-face
        {font-family:Tahoma}
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif"}
a:link, span.MsoHyperlink
        {color:blue;
        text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
        {color:purple;
        text-decoration:underline}
span.hoenzb
        {}
span.EmailStyle18
        {font-family:"Calibri","sans-serif";
        color:#1F497D}
.MsoChpDefault
        {font-family:"Calibri","sans-serif"}
@page WordSection1
        {margin:70.85pt 70.85pt 70.85pt 70.85pt}
div.WordSection1
        {}
-->
</style>
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">I agree about the importance of this feature. In our company we are now avoiding the use of armatures as much as possible, because of the armature problem.
 Instead we’re appending structures of linked groups. (jech)</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">Does this proposal also mean that for example when you have multiple instances of a linked group, you can apply different materials to them?
</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D">Jonatan</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri","sans-serif"; color:#1F497D"> </span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt; font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt; font-family:"Tahoma","sans-serif""> bf-animsys-bounces@blender.org [mailto:bf-animsys-bounces@blender.org]
<b>On Behalf Of </b>Jeffrey H<br>
<b>Sent:</b> zaterdag 7 juni 2014 7:09<br>
<b>To:</b> Discussion list to assist animation developers<br>
<b>Subject:</b> Re: [Bf-animsys] Library Linking and Proxy System reboot</span></p>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">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.
</p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> </p>
<div>
<p class="MsoNormal">On Fri, Jun 6, 2014 at 7:06 AM, Nathan Vegdahl <<a href="mailto:nathanvegdahl@gmail.com" target="_blank">nathanvegdahl@gmail.com</a>> wrote:</p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">> but I thought this was already a gooseberry target?</p>
</div>
<p class="MsoNormal">If it is, I haven't seen it mentioned in any of the blog posts.<br>
Unless it's just assumed to be part of the "asset manager" target.<br>
<br>
But either way, I'd like it to be a specific target of its own, rather<br>
than vaguely part of some category that includes e.g. cloud tools.<br>
It's too easy for it to get lost or forgotten as a target that way.<br>
<span style="color:#888888"><br>
<span class="hoenzb">--Nathan</span></span></p>
<div>
<div>
<p class="MsoNormal"><br>
On Thu, Jun 5, 2014 at 11:37 PM, Bassam Kurdali <<a href="mailto:bassam@urchn.org">bassam@urchn.org</a>> wrote:<br>
> +400000<br>
> but I thought this was already a gooseberry target?<br>
> On Thu, 2014-06-05 at 17:05 -0700, Nathan Vegdahl wrote:<br>
>> Back in February I broached the topic of improving the library linking<br>
>> system as part of the Gooseberry technical targets:<br>
>> <a href="http://lists.blender.org/pipermail/bf-committers/2014-February/042812.html" target="_blank">
http://lists.blender.org/pipermail/bf-committers/2014-February/042812.html</a><br>
>><br>
>> I'd like to continue that discussion here on the bf-animsys mailing<br>
>> list, as suggested by Ton.<br>
>><br>
>> A quick summary:<br>
>> The core problem is that you cannot locally animate or otherwise<br>
>> modify library-linked data in your scene.  Currently Blender has a<br>
>> "proxy" system that works around this limitation for armatures, but it<br>
>> has a lot of weird quirks and is limited to armatures.  This is a<br>
>> severe limitation and production workflow problem for Blender.<br>
>><br>
>> My current tentative proposal is outlined in the link above, and is<br>
>> further clarified in these links:<br>
>> <a href="http://lists.blender.org/pipermail/bf-committers/2014-February/042814.html" target="_blank">
http://lists.blender.org/pipermail/bf-committers/2014-February/042814.html</a><br>
>> <a href="http://lists.blender.org/pipermail/bf-committers/2014-February/042822.html" target="_blank">
http://lists.blender.org/pipermail/bf-committers/2014-February/042822.html</a><br>
>><br>
>> I think this is an extremely important topic that has been repeatedly<br>
>> overlooked over the past few years because:<br>
>><br>
>> 1. It really only becomes a major issue in complex productions, of<br>
>> which there are (currently) few done in Blender.  Therefore most<br>
>> Blender users (and many developers) have difficulty seeing why it's<br>
>> such a horrible situation.<br>
>><br>
>> 2. We have hacky workarounds that are "good enough" to make excuses<br>
>> and push it down as lower-priority than other development goals.<br>
>><br>
>> 3. It's an "unsexy" problem that doesn't strictly change what Blender<br>
>> can produce, it only improves workflow.<br>
>><br>
>> But really, this is a serious issue that significantly hinders<br>
>> efficient, scalable, and intuitive workflows in Blender productions.<br>
>> And I admit that am disappointed that it doesn't appear to be a<br>
>> specific technical target for Gooseberry, which as far as I know is<br>
>> largely about improving production workflow in Blender.  (Unless I<br>
>> missed it? <a href="http://gooseberry.blender.org/may-developer-meetings/" target="_blank">
http://gooseberry.blender.org/may-developer-meetings/</a>)<br>
>><br>
>> Can we please add this as a specific technical target for Gooseberry?<br>
>> And let's further discuss design and how we can go about this.<br>
>><br>
>> Thanks!<br>
>><br>
>> --Nathan<br>
><br>
><br>
_______________________________________________<br>
Bf-animsys mailing list<br>
<a href="mailto:Bf-animsys@blender.org">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></p>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<br>
-- </p>
<div>
<p class="MsoNormal">Jeffrey "Italic_" Hoover</p>
</div>
</div>
</div>
------------------------------------------------------------- This e-mail is intended exclusively for the addressee. If you are not the addressee you must not read, copy, use or disclose the e-mail nor the content; please notify us immediately [by clicking
 'Reply'] and delete this e-mail.
</body>
</html>