<div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><span class="gmail-im">On Wed, Aug 12, 2020 at 7:23 PM Brian Savery <<a href="mailto:brian.savery@gmail.com" target="_blank">brian.savery@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>We're
 more than willing to move ahead with our addon, but for sure it would 
work better eventually being more tightly integrated and we're certainly
 willing to contribute this to blender code.<br></div></div></div></blockquote><div><br></div></span><div>I
 think native Hydra support in Blender makes sense, but it's probably 
too early for us to maintain this now. We are still working on more 
basic USD export and import.<br></div><div><br></div><div>Incremental 
improvements towards this sense though, like moving towards shared 
libraries, extended support for exporting materials and whatever else is
 needed for USD to work well.<br></div><span class="gmail-im"><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 dir="ltr"><div class="gmail_quote"><div><b>Shaders</b> - We see a few options:</div><div>1. 
 Translate material nodegraph simply to USDShade nodes.  This would mean
 that a USDShade node for "PrincipledSurface" for example with all the 
inputs and connections defined<br>     Pro:  Simple<br>     Con:  Hydra render delegates would have to know the blender nodes, most won't.<br>2.  Same as 1, include OSL source from cycles</div><div>     Pro:  Many render delegates handle OSL. Simple for the hydra render engine</div><div>     Cons:  Many do not</div><div>3. 
 Translate Blender nodes to MaterialX node defs.  You can use osl source
 for materialX nodes as well, but to make it most portable you would 
define meta-nodes of Blender Nodes using the materialX standard nodes</div><div> 
   Pros:  Very portable, many renderers handle materialX or at least OSL
 and then by extension materialX.  Use built in Blender nodegraph for 
materials.</div><div>    Cons:  Complexity of defining meta-nodes of Blender nodes in materialx nodes.  Render delegate has to support materialX<br>4.  Hydra render delegate has its own material nodegraph which ONLY allows materialX nodes.  <br>     Pros:  No need to define meta-nodes of Blender nodes</div><div>     Cons:   Render Delegate has to support materialX or OSL</div><div><br></div><div>My
 preference is 3 or 4.  We haven't gotten to this in development yet.  
(we just translate Principled BSDF to USDStandardSurface<br></div></div></div></blockquote><div><br></div></span><div>I
 don't immediately know what the right choice is. How does other 
software handle this, which choice would make it so that a Hydra render 
delegate written to work in e.g. Maya and Houdini also works in Blender 
with minimal changes?</div><div><br></div><div>Do we expect such 
translations to be complete and usable for production? Or would 
renderers still register their own shader nodes anyway, and this would 
just be an approximation of Blender materials? Is there even enough of a
 standard to translate shader nodes for e.g. hair and volumes?</div><div> </div><div>In
 practice we may end up with multiple ways to export shaders, or 
renderers may have their own export paths for shaders. But ideally we 
wouldn't need to.<br></div><span class="gmail-im"><div><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 dir="ltr"><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">
In the devtalk thread, there is an example node graph that reads a USD file<br>
which is then connected to a Render USD via Hydra node, and in that node<br>
RPR is selected as the renderer. With a node graph like that, would not<br>
have the ability to view the same scene with different engines in different<br>
viewports, inspect the resulting scene hierarchy in the outliner, or<br>
select/hide/isolate objects in the viewport?<br></blockquote><div><br></div><div>One could see having different "Output nodes" or sockets in a single output node for Viewport vs Final rendering.  <br></div></div></div></blockquote><div><br></div></span><div>I
 can see how we'd want to have parameters for such node graphs, and an example use case would be to use a more detailed variation for final 
rendering. But I don't think that would involve multiple output nodes. 
The way I see it the output is one Blender collection. And that 
collection in turn can be used for rendering, or export, or preview, or 
something else. But that's not specified by this node graph.</div><div class="gmail-adL"><br></div></div></div></div></div>