<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div>Very good discussion. <br>Maybe at a logistical level what is the best way to continue this? Here, or by submitting a design document to <a href="http://developer.blender.org">developer.blender.org</a>? 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. (BTW of course we have our internal design document we can share)<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Hydra integration for renderers is worthy of its own design document.<br>
There's many technical challenges: how to translate shaders, how to<br>
integrate with the dependency graph for incremental updates in viewport<br>
rendering, how Hydra integrates with the render engine API, and so on.<br>
<br></blockquote><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><br><b>Incremental updates for viewport</b></div><div>Same as issue for other render engines. Mainly look at depsgraph updates, and update items from that. Perhaps one other way to do this is with a USD Scene Delegate: <a href="https://graphics.pixar.com/usd/docs/api/class_hd_scene_delegate.html">https://graphics.pixar.com/usd/docs/api/class_hd_scene_delegate.html</a><br><br><b>Hydra interacting with the render engine api:</b><br>We have a python render engine addon that calls C++ which launches hydra, etc. This is using python bindings from USD/ Hydra</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">
On the practical side of things for this add-on, it makes sense for us to<br>
move to shared libraries for Blender, for reasons besides Hydra. It's a<br>
complex change so we haven't prioritized it so far (if we do it for USD we<br>
also need to do it for all of USD's dependencies). An API function to<br>
convert a depsgraph to USD and provide a pointer also seems reasonable.<br>
<br>
<br>
By itself, Hydra does not require design for the user workflow or changes<br>
to Blender public data structures. The user would not even need to be aware<br>
that Hydra is there under the hood, it would just transparently be used for<br>
final, viewport and preview renders. Where user workflow comes in is USD<br>
node graphs.<br></blockquote><div>Agreed </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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. </div><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">
<br>
So what I'm proposing is that such a node graph should feed into the<br>
Blender scene hierarchy, to support interactive inspection, editing and<br>
overrides. It doesn't mean conversion to Blender data structures is always<br>
done, just that it is possible.<br>
<br></blockquote><div><br></div><div>This is somewhat similar to how the Maya USD plugin works, that referenced USD data shows up in the scene hierarchy and where we were thinking as well. The part we haven't completely finished is when the node graph updates, that you update the scene hierarchy data, but that doesn't seem impossible. </div><div><br>So I think we're aligned mostly in thinking about things. Or at least have the same questions and general ideas. </div></div></div>