<div dir="ltr"><div dir="ltr"><div>Hi Michael,</div><div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 28, 2020 at 10:43 PM Michael A Kowalski <<a href="mailto:makowalski@nvidia.com" target="_blank">makowalski@nvidia.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US"><div><p class="MsoNormal">Thank you very much for sharing the design document regarding using collections as part of the USD integration in Blender (
<a href="https://developer.blender.org/T68933" target="_blank">https://developer.blender.org/T68933</a> ).  We have some follow-up questions to better understand the proposed design:</p>
<p class="MsoNormal"> </p>
<ul style="margin-top:0in" type="disc">
<li style="margin-left:2.25pt">What would the user interface for setting export properties look like?  Would there still be an export dialog or panel for setting global properties (like in the current exporter)
 and a UI for setting export properties on a given collection as well?  It seems that the ability to apply export settings per collection would be important.  For example, if a collection represents a USD sublayer, one might want to specify a save path for
 that layer.</li></ul></div></div></blockquote><div>The export settings would be per collection. Most likely the properties editor would get a new tab for settings of the active collection, and the export settings would be there.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div><ul style="margin-top:0in" type="disc"><li style="margin-left:2.25pt">The document states that “evolving Blender Collections to match USD Layers more closely would help integrate well with USD”.  Can you elaborate on what this might entail?</li></ul></div></div></blockquote><div class="gmail_quote">There's many things we can do here, but some things that come to mind:<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">* USD Xform prims are closest to collection instances in Blender, in that they have a transform and can instance objects. However Blender collection instances were only designed to instance a collection that already exists elsewhere, you can't directly edit their contents in the 3D viewport. So the idea would be to make these collection instances work more like group objects in other applications, where you can edit their contents in-place. This would be a major change, but something that users want regardless of USD.<br></div><div class="gmail_quote">* Blender has no concept of variants, this should become a native feature of Blender collections or datablocks in general.</div><div class="gmail_quote">* USD has more flexible definitions of pivot points, transform order, ... we may need to support that natively in Blender too.</div><div class="gmail_quote">* Blender collections and objects have enable/disable toggles for render and viewport. Instead we could use something like USD purpose and active/inactive, also for Blender itself it would be good to have an explicit distinction between render/proxy/guide objects.<br></div></div><div class="gmail_quote"><div class="gmail_quote"><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div><ul style="margin-top:0in" type="disc"><li style="margin-left:2.25pt">Regarding the point that USD or Alembic files would be “non-editable by default and then support overrides and make local just like linked datablocks”, can you describe some ideas
 of how this data and UX might be presented to the user?</li></ul></div></div></blockquote><div class="gmail_quote">It would be the same as the existing UX for linked datablocks and overrides (which is currently undergoing changes in 2.90 and 2.91).</div><div class="gmail_quote"><br></div><div class="gmail_quote">Linked datablocks by default can't be edited, their properties are grayed out and you can't go into edit mode. If you want to edit them, you typically go into the outliner, right-click and make an independent local copy, or make a local copy with overrides. And then from that point you can edit them just like any other datablock.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Regards,</div><div class="gmail_quote">Brecht.<br></div></div></div>