[Bf-usd] Hello!

[Mark Tucker]

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


On 10/26/2020 5:04:54 AM, Ton Roosendaal <ton at blender.org> wrote:
Hi Mark,
A very interesting question for you then is:  can you share info on how Houdini integrates with USD and how to make sure Blender will work flawlessly in mixed software pipelines?
Thanks,

-Ton-
----------------------------------------------------------------------
Ton Roosendaal - ton at blender.org [mailto:ton at blender.org] - www.blender.org [http://www.blender.org]
Chairman Blender Foundation, Director Blender Institute
Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands



On 26/10/2020 00:57, Mark Tucker wrote:

My intent was to stay on topic, but perhaps I was not clear in my question. Let me try again:

Is Blue Sky using Blender to produce USD assets in production at the moment? And if so, can you tell us a little bit about the process.

I am happy to have this conversation off-list with Chris if you would prefer, Ton. I am new to this list, and there has not been a lot of traffic, so I'm just making some guesses about what would constitute on and off topic here.

Thanks,
Mark
On 10/25/2020 9:46:33 AM, Ton Roosendaal <ton at blender.org> [mailto:ton at blender.org] wrote:
Hi,
It looks like a diverse range of companies participate in this list now. Everyone's really welcome!

However, I always insist on a strict policy to stay on topic on our mailing lists. We are here to discuss how to improve Blender with USD integration.

If you are curious to hear who's using Blender for what, please use private mails.

Thanks,

-Ton-
----------------------------------------------------------------------
Ton Roosendaal - ton at blender.org [mailto:ton at blender.org] - www.blender.org [http://www.blender.org]
Chairman Blender Foundation, Director Blender Institute
Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands



On 25/10/2020 04:19, Mark Tucker wrote:

Hi Chris!

Is Blue Sky using Blender in production at the moment?

Mark
On 10/24/2020 9:26:47 PM, Chris Rydalch <crydalch at gmail.com> [mailto:crydalch at gmail.com] wrote:
Hello! I'm Chris Rydalch, I'm in Production Technology at Blue Sky, helping with our new pipeline. I’m primarily involved with USD Workflows and tools, particularly Houdini; but I’m really excited to see where USD and Blender will go.

Looking forward to joining the discussions!

Thanks!

Chris
-- Bf-usd mailing list Bf-usd at blender.org [mailto:Bf-usd at blender.org] https://lists.blender.org/mailman/listinfo/bf-usd [https://lists.blender.org/mailman/listinfo/bf-usd]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-usd/attachments/20201026/e2f8fe84/attachment.htm>