[Bf-usd] Blender Collections & USD

[Brian Savery]

Very good discussion.
Maybe at a logistical level what is the best way to continue this?  Here,
or by submitting a design document to developer.blender.org?  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)


>
> Hydra integration for renderers is worthy of its own design document.
> There's many technical challenges: how to translate shaders, how to
> integrate with the dependency graph for incremental updates in viewport
> rendering, how Hydra integrates with the render engine API, and so on.
>
> *Shaders* - We see a few options:
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
     Pro:  Simple
     Con:  Hydra render delegates would have to know the blender nodes,
most won't.
2.  Same as 1, include OSL source from cycles
     Pro:  Many render delegates handle OSL. Simple for the hydra render
engine
     Cons:  Many do not
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
    Pros:  Very portable, many renderers handle materialX or at least OSL
and then by extension materialX.  Use built in Blender nodegraph for
materials.
    Cons:  Complexity of defining meta-nodes of Blender nodes in materialx
nodes.  Render delegate has to support materialX
4.  Hydra render delegate has its own material nodegraph which ONLY allows
materialX nodes.
     Pros:  No need to define meta-nodes of Blender nodes
     Cons:   Render Delegate has to support materialX or OSL

My preference is 3 or 4.  We haven't gotten to this in development yet.
(we just translate Principled BSDF to USDStandardSurface

*Incremental updates for viewport*
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:
https://graphics.pixar.com/usd/docs/api/class_hd_scene_delegate.html

*Hydra interacting with the render engine api:*
We have a python render engine addon that calls C++ which launches hydra,
etc.  This is using python bindings from USD/ Hydra


> On the practical side of things for this add-on, it makes sense for us to
> move to shared libraries for Blender, for reasons besides Hydra. It's a
> complex change so we haven't prioritized it so far (if we do it for USD we
> also need to do it for all of USD's dependencies). An API function to
> convert a depsgraph to USD and provide a pointer also seems reasonable.
>
>
> By itself, Hydra does not require design for the user workflow or changes
> to Blender public data structures. The user would not even need to be aware
> that Hydra is there under the hood, it would just transparently be used for
> final, viewport and preview renders. Where user workflow comes in is USD
> node graphs.
>
Agreed

>
> In the devtalk thread, there is an example node graph that reads a USD file
> which is then connected to a Render USD via Hydra node, and in that node
> RPR is selected as the renderer. With a node graph like that, would not
> have the ability to view the same scene with different engines in different
> viewports, inspect the resulting scene hierarchy in the outliner, or
> select/hide/isolate objects in the viewport?
>

One could see having different "Output nodes" or sockets in a single output
node for Viewport vs Final rendering.


> So what I'm proposing is that such a node graph should feed into the
> Blender scene hierarchy, to support interactive inspection, editing and
> overrides. It doesn't mean conversion to Blender data structures is always
> done, just that it is possible.
>
>
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.

So I think we're aligned mostly in thinking about things.  Or at least have
the same questions and general ideas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-usd/attachments/20200812/00ca64d9/attachment.htm>