[Bf-usd] Bf-usd Digest, Vol 3, Issue 3

[Brian Savery]

Blazj, Mark et all.

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.


1.  Allow USD / Hydra to be a render engine inside Blender.  This enables
other USD Hydra render delegates.
https://youtu.be/qUSQa4XEEGg

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.
https://youtu.be/BDf0yxZFbUI

3.  Allow MaterialX materials for renderer agnostic shader node graphs.
(Work in progress)

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.

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?

Brian


>
> Hi everyone,
>
> I'm the pipeline supervisor at Tangent Animation.
>
> 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.
> 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.
>
> For us Layout and Rigs in Animation are the main use-cases, which someone
> dictates our approach.
>
> As opposed to Houdini we went with the Animal Logic-, now Autodesk, way of
> handling the references among the native blender hierarchy.
> 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).
>
> This work among the Usd im- and export on our side will be available
> shortly (currently awaiting clearance from legal).
>
> The other work is hdcycles, already available in our github repository:
> https://github.com/tangent-opensource/hdcycles
>
> Some more additions to it are also planned to be released soon.
> 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.
>
> 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.
> We hope that this will get clearer once the code is released and spawn-off
> more discussions.
> 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.
>
> 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.
>
> Cheers,
> Blazej Floch
>
> ________________________________
> From: Bf-usd <bf-usd-bounces at blender.org> on behalf of Mark Tucker <
> mtucker at sidefx.com>
> Sent: Monday, October 26, 2020 16:28
> To: bf-usd at blender.org <bf-usd at blender.org>
> Subject: Re: [Bf-usd] Hello!
>
> Of course! At least the first part of the question. The second part I can
> give some opinions...
>
> 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.
>
> 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).
>
> 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.
>
> This is the front page of the Houdini documentation relating to Solaris
> for more information:
> https://www.sidefx.com/docs/houdini/solaris/index.html Or please feel
> free to ask more detailed questions.
>
> 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.
>
> Looking at this document: https://developer.blender.org/T68933, 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...
>
> 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.
>
> Mark
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-usd/attachments/20201026/261f57bb/attachment.htm>