<div dir="ltr"><div class="gmail_quote"><div>Blazj, Mark et all. <br><br>Nice to see the interest here for USD in Blender.  We (AMD) are also thinking the same thing and are in the midst of an addon that does a few things.<br><br><br>1.  Allow USD / Hydra to be a render engine inside Blender.  This enables other USD Hydra render delegates. </div><div><a href="https://youtu.be/qUSQa4XEEGg">https://youtu.be/qUSQa4XEEGg</a></div><div><br>2.  Enable USD hierarchy authoring and editing inside a node graph in Blender.  This is admittedly inspired by Houdini Solaris, Katana and others (we support all vendors, but felt Blender users need some simple tools!). While we haven't solved all the issues Mark mentioned about editing Blender data as a sublayer, it does already allow assembling complex graphs and only referencing in data at render time, which to be honest is not currently Blender's strong suit.</div><div><a href="https://youtu.be/BDf0yxZFbUI">https://youtu.be/BDf0yxZFbUI</a><br></div><div><br></div><div>3.  Allow MaterialX materials for renderer agnostic shader node graphs. (Work in progress)</div><div><br></div><div>We're currently looking to open this up in November and would strongly appreciate community development! But hopefully the two videos are a slight teaser.</div><div><br></div><div>It sounds like there are a bunch of strong ideas about enabling tighter USD integration.  Is there plans for a group meeting so we're not all reproducing each others' work?</div><div><br>Brian</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"><br>
Hi everyone,<br>
<br>
I'm the pipeline supervisor at Tangent Animation.<br>
<br>
I am glad that you bring up some of the points. We are already somewhat involved into developing Usd handling in Blender, that goes beyond just im-/export.<br>
As we speak our main developer, Charles Wardlaw, has been trying to answer some of the question of how to handle edits of referenced Usd data.<br>
<br>
For us Layout and Rigs in Animation are the main use-cases, which someone dictates our approach.<br>
<br>
As opposed to Houdini we went with the Animal Logic-, now Autodesk, way of handling the references among the native blender hierarchy.<br>
We may also end-up representing our edits in an Usd SessionLayer, while exposing the controls via a native blender element (comparable to the ephemeral Proxy objects in Maya).<br>
<br>
This work among the Usd im- and export on our side will be available shortly (currently awaiting clearance from legal).<br>
<br>
The other work is hdcycles, already available in our github repository:<br>
<a href="https://github.com/tangent-opensource/hdcycles" rel="noreferrer" target="_blank">https://github.com/tangent-opensource/hdcycles</a><br>
<br>
Some more additions to it are also planned to be released soon.<br>
We're glad that the Blender Foundation started the Usd integration and hope we can contribute our work based on it for a broader ecosystem of DCCs utilizing Usd.<br>
<br>
That being said - we are working under production constraints, so it may be a mere starting-point that needs more work to make if viable for a broader audience within Blender.<br>
We hope that this will get clearer once the code is released and spawn-off more discussions.<br>
Then we hopefully can also shed some light on our workflows that will allow asset, layout and animation work in Blender, while playing nicely with other workflows in Houdini via Usd exchange.<br>
<br>
I am also curious about the potential that this might bring to other studios, as blender shines in certain workflows and it would be interesting to see how opening it up to existing pipelines via Usd affects its role in the production landscape.<br>
<br>
Cheers,<br>
Blazej Floch<br>
<br>
________________________________<br>
From: Bf-usd <<a href="mailto:bf-usd-bounces@blender.org" target="_blank">bf-usd-bounces@blender.org</a>> on behalf of Mark Tucker <<a href="mailto:mtucker@sidefx.com" target="_blank">mtucker@sidefx.com</a>><br>
Sent: Monday, October 26, 2020 16:28<br>
To: <a href="mailto:bf-usd@blender.org" target="_blank">bf-usd@blender.org</a> <<a href="mailto:bf-usd@blender.org" target="_blank">bf-usd@blender.org</a>><br>
Subject: Re: [Bf-usd] Hello!<br>
<br>
Of course! At least the first part of the question. The second part I can give some opinions...<br>
<br>
Houdini's USD integration sprang from a desire to implement a new (Katana-like) node based look development and lighting environment within Houdini, called Solaris. We determined that USD (combined with Hydra) provided many of the critical capabilities that our users wanted in this new context, so we decided to build this new context from the ground up around USD.<br>
<br>
So as of version 18.0, Houdini ships with the USD library built in. There is a new node context called LOPs which provides native editing of USD data. Which is to say LOPs load USD data directly, manipulates it directly as USD, display it in the 3D viewport using the Hydra framework, and outputs USD. Many LOPs focus on look development and lighting-specific tasks, but we also provide LOP nodes for more generic USD authoring tasks (such as creating variants, adding references, authoring USD Point Instancer primitives, etc).<br>
<br>
Because this USD editing all happens within a specific Houdini context, the user can choose whether to use USD exclusively, of Houdini representations exclusively, or combine their capabilities using explicit translation nodes (import from LOPs into SOPs or SOPs into LOPs). But our plan in the fairly near term is to convince users to move all lighting work into the Solaris/LOP context.<br>
<br>
This is the front page of the Houdini documentation relating to Solaris for more information: <a href="https://www.sidefx.com/docs/houdini/solaris/index.html" rel="noreferrer" target="_blank">https://www.sidefx.com/docs/houdini/solaris/index.html</a> Or please feel free to ask more detailed questions.<br>
<br>
As for Blender (and any DCC integrating with USD through explicit Import/Export translation workflows) the difficult part, I think, is the export step. USD is always read in as a composed stage (and so the import step can be handled like any other external data format). But that stage is made up of many, many layer files. Often multiple files contribute to any given primitive in the scene graph. So authoring changes to the stage requires an understanding of how those changes will be consumed by the next application in the pipeline. And there are limitations on what kinds of edits can be performed, depending on how the edits are applied. The application may want to directly edit one or more source layers. Or it may author overrides to a particular branch of the scene graph that needs to be referenced onto the stage. Or it can author scene-wide overrides that must be applied as a sublayer. Or it can author only brand new data (no overrides) that can then be brought back onto the stage using any USD composition arc.<br>
<br>
Looking at this document: <a href="https://developer.blender.org/T68933" rel="noreferrer" target="_blank">https://developer.blender.org/T68933</a>, it sounds to me like it might align well with the "author a new sublayer" approach? The Blender Collection sounds like it could contain the loaded objects from the USD stage, and hold configuration information for writing out changes to the stage authored within the blender session? But I know nothing about how Blender would represent such edits internally prior to exporting them...<br>
<br>
A simpler integration could take the last approach, where Blender is not capable of overriding existing scene graph data, and instead only authors brand new primitives. If Blender is being used primarily as a modeler this is a perfectly viable (if more limited) style of integration, but it does not line up with all the use cases described in that design document.<br>
<br>
Mark<br><br></blockquote></div></div>