[Bf-usd] Blender Collections & USD

[Brecht Van Lommel]

On Wed, Aug 12, 2020 at 7:23 PM Brian Savery <brian.savery at gmail.com> wrote:

> 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.
>

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.

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.


> *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
>

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?

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?

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.

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.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-usd/attachments/20200814/fb48eff4/attachment.htm>