USD Layers referencing, MaterialX, and USD Hydra rendering Addon for Blender #100569

New Issue

Brian Savery (AMD) · 2022-08-22T19:35:11+02:00

2022-08-22 19:35:11 +02:00

Intro

AMD published a "USD Hydra and MaterialX" Addon for Blender https://github.com/GPUOpen-LibrariesAndSDKs/BlenderUSDHydraAddon. Based on that and conversations at SIGGRAPH 2022, the need for Hydra rendering and USD import by referencing into Blender is clear. AMD has been working on a branch of Blender to integrate this work directly in. The goal of this is to serve such needs:

Allow referencing USD into Blender without importing data fully into Blender until render time
USD Hydra rendering which allows connection to many rendering engines without duplicating export code, as well rendering referenced USD data
Option to override Cycles node graphs with MaterialX. USD is agnostic about materials, and having a standard material format which all Hydra renderers can use is key.

Thus this task can be divided into 3 "subtasks" (not sure how to create or track those here)

Import collections for linking USD data to Blender
USD Hydra rendering addon for Blender

MaterialX addon for manipulating MaterialX networks

Much of this we can contribute but some parts may need help from the community and Blender developers.

USD Layers / Collections

To support bringing USD data into Blender and having it function as a linked library, we propose a new type of collection which is a “USD Layer”.

USD Layers would be created similar to Collections in the outliner and be a sub type of collections, but have different collection properties:

USD Import Panel (in Collection Properties
- Path - to USD file on disk
- Import Data / or Reference toggle - Will change behavior if data is imported at time when path is changed or only brought in at render time
- Save button - Save the usd file with current overrides applied
- Refresh button - rescan the file on disk for changes

A USD Layer will be a reference to a USD file. USD “Prims” (objects) in that file are brought into the Blender scene when the USD Layer path changes. They create objects as subtypes of “library data” type. The data blocks (meshes) are only imported if the import toggle on the USD Collection is checked. Thus, the imported collection will have two ways of operating: Import all the USD data into Blender’s memory, or just import the USD skeleton and defer importing data until render time, referencing basically.

Objects created from the USD Collection will have to maintain a link back to the collection and their original USD Prim path in the USD file. USD attributes will be displayed in the spreadsheet editor for the object context.

An example of USD Layers in the outliner. USD Layers would be similar to collections. Note that USD composites data from layers so the order is important.

USD Layer settings

Objects linked to USD layers will have to have a way to set their path in USD

USD Hydra rendering engine addon

The USD Hydra rendering addon is a built-in rendering addon that handles rendering through USD Hydra. It will come with Hydra's GL Storm renderer by default. Users can install Hydra Render Delegates for viewport and final rendering via the addon properties. Many renderers already have Hydra delegates available which users can install. Furthermore, it de-duplicates render export code that each rendering addon does.

Rendering with the Hydra delegate handles Blender data and USD data. Blender data is exported via a USD Hydra Scene Delegate, exporting Blender Data to hydra. When exporting objects that are linked to a USD collection (and are left as a reference, not imported), those objects can be taken directly from the USD. Any overrides of transform, visibility, shader etc to the referenced object done in the blender data can be applied on top of the USD data.

For shaders, the USD Hydra addon will translate cycles node graphs automatically to MaterialX node graphs and attach them to the USD.

MaterialX Nodetree addon

This will be a separate addon that allows users to compose materialX in its own node graph. When enabled, it will give a new node graph type with the MaterialX standard nodes. It will also give an optional setting to override Blender materials with the MaterialX node graph. This option will only be enabled when using along with the USD Hydra renderer.

USD lib requirements

We can expose the USD library as a “monolithic shared library” as well exposing the python bindings. TBD what hooks we should give power users for manipulating USD data from a collection.

We think we can deliver most of this for Blender 3.5. The "translation of cycles to MaterialX" will probably be the hardest part to get right at first, but we can start with simple node graphs.

# **Intro** AMD published a "USD Hydra and MaterialX" Addon for Blender https://github.com/GPUOpen-LibrariesAndSDKs/BlenderUSDHydraAddon. Based on that and conversations at SIGGRAPH 2022, the need for Hydra rendering and USD import by referencing into Blender is clear. AMD has been working on a branch of Blender to integrate this work directly in. The goal of this is to serve such needs: - Allow referencing USD into Blender without importing data fully into Blender until render time - USD Hydra rendering which allows connection to many rendering engines without duplicating export code, as well rendering referenced USD data - Option to override Cycles node graphs with MaterialX. USD is agnostic about materials, and having a standard material format which all Hydra renderers can use is key. Thus this task can be divided into 3 "subtasks" (not sure how to create or track those here) - Import collections for linking USD data to Blender - USD Hydra rendering addon for Blender # MaterialX addon for manipulating MaterialX networks Much of this we can contribute but some parts may need help from the community and Blender developers. # **USD Layers / Collections** To support bringing USD data into Blender and having it function as a linked library, we propose a new type of collection which is a “USD Layer”. USD Layers would be created similar to Collections in the outliner and be a sub type of collections, but have different collection properties: - USD Import Panel (in Collection Properties - Path - to USD file on disk - Import Data / or Reference toggle - Will change behavior if data is imported at time when path is changed or only brought in at render time - Save button - Save the usd file with current overrides applied - Refresh button - rescan the file on disk for changes A USD Layer will be a reference to a USD file. USD “Prims” (objects) in that file are brought into the Blender scene when the USD Layer path changes. They create objects as subtypes of “library data” type. The data blocks (meshes) are only imported if the import toggle on the USD Collection is checked. Thus, the imported collection will have two ways of operating: Import all the USD data into Blender’s memory, or just import the USD skeleton and defer importing data until render time, referencing basically. Objects created from the USD Collection will have to maintain a link back to the collection and their original USD Prim path in the USD file. USD attributes will be displayed in the spreadsheet editor for the object context. **An example of USD Layers in the outliner. USD Layers would be similar to collections. Note that USD composites data from layers so the order is important.** ![Screen Shot 2022-08-15 at 5.55.06 AM.png](https://archive.blender.org/developer/F13411616/Screen_Shot_2022-08-15_at_5.55.06_AM.png) **USD Layer settings** ![Screen Shot 2022-08-15 at 5.54.11 AM.png](https://archive.blender.org/developer/F13411618/Screen_Shot_2022-08-15_at_5.54.11_AM.png) **Objects linked to USD layers will have to have a way to set their path in USD** ![Screen Shot 2022-08-15 at 5.55.26 AM.png](https://archive.blender.org/developer/F13411617/Screen_Shot_2022-08-15_at_5.55.26_AM.png) # **USD Hydra rendering engine addon** The USD Hydra rendering addon is a built-in rendering addon that handles rendering through USD Hydra. It will come with Hydra's GL Storm renderer by default. Users can install Hydra Render Delegates for viewport and final rendering via the addon properties. Many renderers already have Hydra delegates available which users can install. Furthermore, it de-duplicates render export code that each rendering addon does. Rendering with the Hydra delegate handles Blender data and USD data. Blender data is exported via a USD Hydra Scene Delegate, exporting Blender Data to hydra. When exporting objects that are linked to a USD collection (and are left as a reference, not imported), those objects can be taken directly from the USD. Any overrides of transform, visibility, shader etc to the referenced object done in the blender data can be applied on top of the USD data. For shaders, the USD Hydra addon will translate cycles node graphs automatically to MaterialX node graphs and attach them to the USD. # **MaterialX Nodetree addon** This will be a separate addon that allows users to compose materialX in its own node graph. When enabled, it will give a new node graph type with the MaterialX standard nodes. It will also give an optional setting to override Blender materials with the MaterialX node graph. This option will only be enabled when using along with the USD Hydra renderer. # USD lib requirements We can expose the USD library as a “monolithic shared library” as well exposing the python bindings. TBD what hooks we should give power users for manipulating USD data from a collection. We think we can deliver most of this for Blender 3.5. The "translation of cycles to MaterialX" will probably be the hardest part to get right at first, but we can start with simple node graphs.

Brian Savery (AMD) self-assigned this 2022-08-22 19:35:11 +02:00

Brian Savery (AMD) commented

2022-08-22 19:35:11 +02:00

Added subscribers: @BrianSavery, @dr.sybren, @brecht

Ray molenkamp commented

2022-08-22 19:45:07 +02:00

Added subscriber: @LazyDodo

Ray molenkamp commented

2022-08-22 19:45:07 +02:00

USD lib requirements
We can expose the USD library as a “monolithic shared library” as well exposing the python bindings.

The change to a shared USD lib and python bindings we'll likely to ship for 3.4, see #99618 for details

> USD lib requirements > We can expose the USD library as a “monolithic shared library” as well exposing the python bindings. The change to a shared USD lib and python bindings we'll likely to ship for 3.4, see #99618 for details

Brian Savery (AMD) commented

2022-08-22 19:50:25 +02:00

Great let me confirm that's what we'd need.

Ray molenkamp commented

2022-08-22 20:08:23 +02:00

I can send you a preliminary copy of the 3.4 windows libs if you want

Brecht Van Lommel commented

2022-08-22 20:22:43 +02:00

USD Layers would be created similar to Collections in the outliner and be a sub type of collections, but have different collection properties:

This overlaps with the ideas from #68933 and #100367, so we'll need to figure out how this all fits together. It may be best to have that discussion in #100367.

As an aside, user installed closed-source render delegates fix the “GPL problem” many renderers complain about adapting to Blender since it the user assembles the total.

To be clear, the Blender Foundation has not taken a position on this as far as I know, it depends on the interpretation of the GPL.

Regardless I think native Hydra support is important.

MaterialX Nodetree addon

Supporting MaterialX is important, but this also opens up a lot of questions about how to bridge MaterialX and Blender's existing texture/shader nodes, short term and long term. I think we need a two way conversion between Blender shader nodes and MaterialX at least, not just one way.

> USD Layers would be created similar to Collections in the outliner and be a sub type of collections, but have different collection properties: This overlaps with the ideas from #68933 and #100367, so we'll need to figure out how this all fits together. It may be best to have that discussion in #100367. > As an aside, user installed closed-source render delegates fix the “GPL problem” many renderers complain about adapting to Blender since it the user assembles the total. To be clear, the Blender Foundation has not taken a position on this as far as I know, it depends on the interpretation of the GPL. Regardless I think native Hydra support is important. > MaterialX Nodetree addon Supporting MaterialX is important, but this also opens up a lot of questions about how to bridge MaterialX and Blender's existing texture/shader nodes, short term and long term. I think we need a two way conversion between Blender shader nodes and MaterialX at least, not just one way.

Brian Savery (AMD) commented

2022-08-22 20:40:19 +02:00

In #100569#1407220, @brecht wrote:

To be clear, the Blender Foundation has not taken a position on this as far as I know, it depends on the interpretation of the GPL.

Right, sorry I wasn't asking for an opinion from BF here, just pointing out that if the developers of Renderers are complaining they don'e want to adapt their software to Blender because of GPL this is a way to get their support into Blender, since most renderers are supporting Hydra

MaterialX Nodetree addon

Supporting MaterialX is important, but this also opens up a lot of questions about how to bridge MaterialX and Blender's existing texture/shader nodes, short term and long term. I think we need a two way conversion between Blender shader nodes and MaterialX at least, not just one way.

I would question if a true "two-way" conversion is possible or necessary. We're sort of proposing a 1.5 way. Users can convert Blender node graphs to MaterialX, or import MaterialX into Blender for use via Hydra. Is it nesscesary to convert MaterialX back to Cycles node graphs? Most users I see importing in MaterialX would probably be staying rendering in Hydra. There is also the option I suppose to export OSL from MaterialX and then bring that in to Cycles.

> In #100569#1407220, @brecht wrote: > To be clear, the Blender Foundation has not taken a position on this as far as I know, it depends on the interpretation of the GPL. > Right, sorry I wasn't asking for an opinion from BF here, just pointing out that if the developers of Renderers are complaining they don'e want to adapt their software to Blender because of GPL this is a way to get their support into Blender, since most renderers are supporting Hydra >> MaterialX Nodetree addon > > Supporting MaterialX is important, but this also opens up a lot of questions about how to bridge MaterialX and Blender's existing texture/shader nodes, short term and long term. I think we need a two way conversion between Blender shader nodes and MaterialX at least, not just one way. I would question if a true "two-way" conversion is possible or necessary. We're sort of proposing a 1.5 way. Users can convert Blender node graphs to MaterialX, or import MaterialX into Blender for use via Hydra. Is it nesscesary to convert MaterialX back to Cycles node graphs? Most users I see importing in MaterialX would probably be staying rendering in Hydra. There is also the option I suppose to export OSL from MaterialX and then bring that in to Cycles.

Brecht Van Lommel commented

2022-08-22 20:46:43 +02:00

In #100569#1407228, @BrianSavery wrote:
I would question if a true "two-way" conversion is possible or necessary. We're sort of proposing a 1.5 way. Users can convert Blender node graphs to MaterialX, or import MaterialX into Blender for use via Hydra. Is it nesscesary to convert MaterialX back to Cycles node graphs? Most users I see importing in MaterialX would probably be staying rendering in Hydra. There is also the option I suppose to export OSL from MaterialX and then bring that in to Cycles.

We don't have OSL support in Eevee or Cycles GPU rendering currently, so that would only be a partial solution. Also texture baking tools.

For Blender I think it's important for its own renderers to be able to render MaterialX graphs created in other software, one way or another. For external renderers it's not an issue of course, just from the point of view of Blender users in general I think this gap in functionality will be important to tackle.

> In #100569#1407228, @BrianSavery wrote: > I would question if a true "two-way" conversion is possible or necessary. We're sort of proposing a 1.5 way. Users can convert Blender node graphs to MaterialX, or import MaterialX into Blender for use via Hydra. Is it nesscesary to convert MaterialX back to Cycles node graphs? Most users I see importing in MaterialX would probably be staying rendering in Hydra. There is also the option I suppose to export OSL from MaterialX and then bring that in to Cycles. We don't have OSL support in Eevee or Cycles GPU rendering currently, so that would only be a partial solution. Also texture baking tools. For Blender I think it's important for its own renderers to be able to render MaterialX graphs created in other software, one way or another. For external renderers it's not an issue of course, just from the point of view of Blender users in general I think this gap in functionality will be important to tackle.

👍 1

Brian Savery (AMD) commented

2022-08-22 21:10:03 +02:00

In #100569#1407244, @brecht wrote:

In #100569#1407228, @BrianSavery wrote:
I would question if a true "two-way" conversion is possible or necessary. We're sort of proposing a 1.5 way. Users can convert Blender node graphs to MaterialX, or import MaterialX into Blender for use via Hydra. Is it nesscesary to convert MaterialX back to Cycles node graphs? Most users I see importing in MaterialX would probably be staying rendering in Hydra. There is also the option I suppose to export OSL from MaterialX and then bring that in to Cycles.

We don't have OSL support in Eevee or Cycles GPU rendering currently, so that would only be a partial solution. Also texture baking tools.

For Blender I think it's important for its own renderers to be able to render MaterialX graphs created in other software, one way or another. For external renderers it's not an issue of course, just from the point of view of Blender users in general I think this gap in functionality will be important to tackle.

Let's discuss in the rendering meeting tomorrow. I don't disagree, but definitely needs some input from EEVEE or Cycles to help out here. The main issue I see is that the MaterialX nodes are lower level (for example Voronoi) than Blender's nodes in many cases.

> In #100569#1407244, @brecht wrote: >> In #100569#1407228, @BrianSavery wrote: >> I would question if a true "two-way" conversion is possible or necessary. We're sort of proposing a 1.5 way. Users can convert Blender node graphs to MaterialX, or import MaterialX into Blender for use via Hydra. Is it nesscesary to convert MaterialX back to Cycles node graphs? Most users I see importing in MaterialX would probably be staying rendering in Hydra. There is also the option I suppose to export OSL from MaterialX and then bring that in to Cycles. > > We don't have OSL support in Eevee or Cycles GPU rendering currently, so that would only be a partial solution. Also texture baking tools. > > For Blender I think it's important for its own renderers to be able to render MaterialX graphs created in other software, one way or another. For external renderers it's not an issue of course, just from the point of view of Blender users in general I think this gap in functionality will be important to tackle. Let's discuss in the rendering meeting tomorrow. I don't disagree, but definitely needs some input from EEVEE or Cycles to help out here. The main issue I see is that the MaterialX nodes are lower level (for example Voronoi) than Blender's nodes in many cases.

Michael Kowalski commented

2022-08-22 21:54:56 +02:00

Added subscriber: @makowalski

Alaska commented

2022-08-23 03:03:41 +02:00

Added subscriber: @Alaska

Nana Beniako commented

2022-08-23 13:24:14 +02:00

Added subscriber: @Roggii-4

Yuro commented

2022-08-23 15:46:53 +02:00

Added subscriber: @Yuro

platerytter blandebord commented

2022-08-23 19:07:06 +02:00

Added subscriber: @platerytter

Philipp Oeser commented

2022-08-23 20:15:49 +02:00

Added subscriber: @lichtwerk

James Barrie commented

2022-08-23 21:14:45 +02:00

Added subscriber: @JamesBarrie

Andrew Charlton commented

2022-08-24 05:57:18 +02:00

Added subscriber: @Scaredyfish

Paul Golter commented

2022-08-24 14:38:34 +02:00

Added subscriber: @paulgolter

Zhen Dai commented

2022-08-25 04:36:02 +02:00

Added subscriber: @Zhen-Dai

Julian Eisel commented

2022-08-25 16:10:42 +02:00

Added subscriber: @JulianEisel

Julian Eisel commented

2022-08-25 16:10:42 +02:00

As an aside, user installed closed-source render delegates fix the “GPL problem” many renderers complain about adapting to Blender since it the user assembles the total.

The GPL FAQ from the FSF seems to disagree with this (at least in a different case, if comparable or not is a different question):

Yes, this is a violation, because effectively this makes a larger combined work. The fact that the user is expected to put the pieces together does not really change anything.

https://www.gnu.org/licenses/gpl-faq.html#NonfreeDriverKernelLinux/
Typically the BF seems to follow such FSF guidance.

Hydra support would definitely be great. Just noting that the licensing topic needs further checking with the BF.

> As an aside, user installed closed-source render delegates fix the “GPL problem” many renderers complain about adapting to Blender since it the user assembles the total. The GPL FAQ from the FSF seems to disagree with this (at least in a different case, if comparable or not is a different question): > Yes, this is a violation, because effectively this makes a larger combined work. The fact that the user is expected to put the pieces together does not really change anything. https://www.gnu.org/licenses/gpl-faq.html#NonfreeDriverKernelLinux/ Typically the BF seems to follow such FSF guidance. Hydra support would definitely be great. Just noting that the licensing topic needs further checking with the BF.

Brian Savery (AMD) commented

2022-08-25 16:33:55 +02:00

@JulianEisel I'm not going to further argue the point. It was meant as an aside which I can remove from this design if objectionable.

Ahmed Hindy commented

2022-08-25 19:18:47 +02:00

Added subscriber: @ahmed.hindy96

Ian Hsieh commented

2022-08-25 19:26:47 +02:00

Added subscriber: @ianhsieh

Ian Hsieh commented

2022-08-25 19:26:47 +02:00

This looks great, Brian! Just a couple of questions from a render delegate point of view:

How will render delegates register their own render options, so that it gets included in the USD file?
How do you deal with renderers that have other plugin types? RenderMan has integrators, light filters, sample filters etc. How will these show up in the UI?
Can delegates specify different output types for AOVs? I believe hydra still doesn't deal with deep.

This looks great, Brian! Just a couple of questions from a render delegate point of view: 1. How will render delegates register their own render options, so that it gets included in the USD file? 2. How do you deal with renderers that have other plugin types? RenderMan has integrators, light filters, sample filters etc. How will these show up in the UI? 3. Can delegates specify different output types for AOVs? I believe hydra still doesn't deal with deep.

Brian Savery (AMD) commented

2022-08-26 00:25:33 +02:00

In the case like this (RenderMan, Arnold etc). They would just have to install some UI addons to Blender, to customize the UI settings for their renderer.... i.e

class RenderManHydraSettingsPanel(Panel):
    .... bl_info settings
    ... 
    def poll(self, context):
          return context.engine == "HYDRA" and context.scene.hydra.render_delegate == "RENDERMAN" 

    def draw(self, context):
        ... draw settings

And we would have to provide some function (in a class type that can be overriden) to inject the render settings into the USD stream as well. Because the USD Python api is being exposed this shouldn't be too hard.

I mean the RenderMan render delegate is loading all it's own plugins right? So like if you pass the "ri:integrator = PxrPathTracer" setting through USD to the RenderMan hydra delegate that should just work? I'm saying this could all be handled in the render settings passed through USD.
My understanding is that AOVs are a handled better in Hydra2, which frankly I haven't looked too deeply at yet. And I'm not sure how ready it is yet?

In the case like this (RenderMan, Arnold etc). They would just have to install some UI addons to Blender, to customize the UI settings for their renderer.... i.e ``` class RenderManHydraSettingsPanel(Panel): .... bl_info settings ... def poll(self, context): return context.engine == "HYDRA" and context.scene.hydra.render_delegate == "RENDERMAN" def draw(self, context): ... draw settings ``` And we would have to provide some function (in a class type that can be overriden) to inject the render settings into the USD stream as well. Because the USD Python api is being exposed this shouldn't be too hard. 2. I mean the RenderMan render delegate is loading all it's own plugins right? So like if you pass the "ri:integrator = PxrPathTracer" setting through USD to the RenderMan hydra delegate that should just work? I'm saying this could all be handled in the render settings passed through USD. 3. My understanding is that AOVs are a handled better in Hydra2, which frankly I haven't looked too deeply at yet. And I'm not sure how ready it is yet?

Satish Goda commented

2022-08-28 01:14:07 +02:00

Added subscriber: @satishgoda1

Esteban Covo commented

2022-08-28 16:33:19 +02:00

Added subscriber: @EstebanCovo

Tristan commented

2022-08-29 09:08:13 +02:00

Added subscriber: @Plyro

Emilien Colombier commented

2022-08-29 21:26:50 +02:00

Added subscriber: @Peine_Perdue

Georgiy Markelov commented

2022-08-30 17:02:05 +02:00

Added subscriber: @DagerD

Alexey Adamitsky commented

2022-08-31 14:22:59 +02:00

Added subscriber: @AlexeyAdamitsky

Georgiy Markelov commented

2022-09-02 17:55:25 +02:00

Hi.

I'm trying to add a new structure (USD Collection), that should be almost similar to regular Blender's Collection. Now Blender builds without errors and I can see that my structure is successfully registered and added to struct Main. But if I run Blender, ED_undo_stack_get() function returns NULL and Blender crashes. I'm stuck with this.

Can anyone give me some advice on how to fix it? @JulianEisel @dr.sybren

Hi. I'm trying to add a new structure (USD Collection), that should be almost similar to regular Blender's Collection. Now Blender builds without errors and I can see that my structure is successfully registered and added to struct Main. But if I run Blender, ED_undo_stack_get() function returns NULL and Blender crashes. I'm stuck with this. Can anyone give me some advice on how to fix it? @JulianEisel @dr.sybren

Brecht Van Lommel commented

2022-09-02 18:11:11 +02:00

@DagerD we should keep this task about the high level design discussion. For help with development I recommend blender.chat or devtalk.blender.org.

Also be aware that the specific design of this is being discussed in #100367, and that the decision may be to extend Blender collections rather than add entirely separate USD collections.

@DagerD we should keep this task about the high level design discussion. For help with development I recommend blender.chat or devtalk.blender.org. Also be aware that the specific design of this is being discussed in #100367, and that the decision may be to extend Blender collections rather than add entirely separate USD collections.

Sonny Campbell commented

2022-09-07 17:02:15 +02:00

Added subscriber: @SonnyCampbell_Unity

Sonny Campbell commented

2022-09-07 17:02:15 +02:00

Hey @DagerD yeah there is already some work underway to integrate USD with collections. There are some specific design goals in place for getting it integrated. If you'd like to join the discussion there is a meeting for the pipelines module tomorrow.

Brian Savery (AMD) commented

2022-09-07 23:39:56 +02:00

Couple comments here:

@LazyDodo We would eventually need the MaterialX libraries available to use for this, both for automatic export of blender nodes, as well as the MaterialX add-on (if this is accepted).
@SonnyCampbell_Unity and @brecht. @DagerD is one of the developers we had helping with our AMD ProRender add-on that was helping here with this (AMD is sponsoring this development and hoping to donate it to Blender). I've been talking with him. We are fairly far along in a private branch that we'd like to move to the public "USD Blender" branch.

The USD Hydra rendering add-on is fairly complete, the MaterialX side needs library support to move it over, but the USD Collections part is the one that is being worked on.

With regards to a "general solution for import collections" that satisfies Blender, I have some concerns.

We're really interested in helping contribute USD support for Blender, I'm not sure the need or desire is there for other file formats, OBJ etc. I'd be willing to speculate that in the VFX industry using Blender, USD referencing is really the one they need (see conversations at siggraph). So making this the general solution might be a bit limiting.
That being said we're basically talking about adding a file import property and a few buttons to the collection type. So maybe this can be abstracted enough that if someone else wants to enable for other file types it might be ok.
That being said, there is a valid reason I think for separating USD "Collections" (I prefer to call them USD Layers) in the outliner. USD has some specific functionality of layering layers. Say for instance that you two USD files, one with an object at path /foo/ball (with a red material) and one with the same path /foo/ball with a blue material. It's very important the order of these layers to resolve the correct material overrides. Does Blender collections have the same functionality? My thought was that we should separate USD Layers from other collections to keep this functionality separate and clear for users, and so that they can rearrange the layers to handle the layering.

Couple comments here: 1. @LazyDodo We would eventually need the MaterialX libraries available to use for this, both for automatic export of blender nodes, as well as the MaterialX add-on (if this is accepted). 2. @SonnyCampbell_Unity and @brecht. @DagerD is one of the developers we had helping with our AMD ProRender add-on that was helping here with this (AMD is sponsoring this development and hoping to donate it to Blender). I've been talking with him. We are fairly far along in a private branch that we'd like to move to the public "USD Blender" branch. The USD Hydra rendering add-on is fairly complete, the MaterialX side needs library support to move it over, but the USD Collections part is the one that is being worked on. With regards to a "general solution for import collections" that satisfies Blender, I have some concerns. 1. We're really interested in helping contribute USD support for Blender, I'm not sure the need or desire is there for other file formats, OBJ etc. I'd be willing to speculate that in the VFX industry using Blender, USD referencing is really the one they need (see conversations at siggraph). So making this the general solution might be a bit limiting. 2. That being said we're basically talking about adding a file import property and a few buttons to the collection type. So maybe this can be abstracted enough that if someone else wants to enable for other file types it might be ok. 3. That being said, there is a valid reason I think for separating USD "Collections" (I prefer to call them USD Layers) in the outliner. USD has some specific functionality of layering layers. Say for instance that you two USD files, one with an object at path /foo/ball (with a red material) and one with the same path /foo/ball with a blue material. It's very important the order of these layers to resolve the correct material overrides. Does Blender collections have the same functionality? My thought was that we should separate USD Layers from other collections to keep this functionality separate and clear for users, and so that they can rearrange the layers to handle the layering.

Esteban Covo commented

2022-09-08 00:37:42 +02:00

I think too that separating USD Layers is not a bad idea at all, even Houdini manages USD as a completely different context to not try to bend the universal standard to it's way of working, studios just take the time to learn it and adapt to the standard, flowing along the standard just makes it easier to invest on building a pipeline around it, since you know it wll play well with the larger industry ecosystem.

I also agree that the need or desire for a better USD pipeline outweights by far something like having a general solution for importing the likes of OBJ, most formats are transitory and you can just make a tool to process them in python, I've never heard of a production that wants to stay in STL or OBJ, hopefully the emphasis on general solutions doesn't hinder a well standarized USD implementation

I think too that separating USD Layers is not a bad idea at all, even Houdini manages USD as a completely different context to not try to bend the universal standard to it's way of working, studios just take the time to learn it and adapt to the standard, flowing along the standard just makes it easier to invest on building a pipeline around it, since you know it wll play well with the larger industry ecosystem. I also agree that the need or desire for a better USD pipeline outweights by far something like having a general solution for importing the likes of OBJ, most formats are transitory and you can just make a tool to process them in python, I've never heard of a production that wants to stay in STL or OBJ, hopefully the emphasis on general solutions doesn't hinder a well standarized USD implementation

Brecht Van Lommel commented

2022-09-08 01:33:50 +02:00

Before deciding if USD collections should be a separate datablock, we really need a design direction for user cases beyond importing external USD files and rendering them in a Hydra. There's creating new USD layers, object selection and editing tools, collection visibility and editing tools, modifiers and geometry nodes, Blender overrides, material assignment, rendering with Cycles & Eevee, etc There's design questions about how data flows between different areas, how best to visualize and edit things pre and post composition in the outliner and 3D viewport, what the user workflow is for editing imported data, etc.

One of the major strengths of Blender is that you can mostly just create in one application without having to deal with all kinds of interop issues. If you end up with two parallel system for collections (and shader graphs), you risk a confusing interface and arbitrary limitations, and difficult maintenance long term. Improving and extending existing functionality to be compatible with USD should be a serious consideration even if adding something new is easier in the short term.

Before deciding if USD collections should be a separate datablock, we really need a design direction for user cases beyond importing external USD files and rendering them in a Hydra. There's creating new USD layers, object selection and editing tools, collection visibility and editing tools, modifiers and geometry nodes, Blender overrides, material assignment, rendering with Cycles & Eevee, etc There's design questions about how data flows between different areas, how best to visualize and edit things pre and post composition in the outliner and 3D viewport, what the user workflow is for editing imported data, etc. One of the major strengths of Blender is that you can mostly just create in one application without having to deal with all kinds of interop issues. If you end up with two parallel system for collections (and shader graphs), you risk a confusing interface and arbitrary limitations, and difficult maintenance long term. Improving and extending existing functionality to be compatible with USD should be a serious consideration even if adding something new is easier in the short term.

Ray molenkamp commented

2022-09-08 18:20:37 +02:00

Added subscriber: @ray-1

Ray molenkamp commented

2022-09-08 18:20:37 +02:00

@LazyDodo We would eventually need the MaterialX libraries available to use for this, both for automatic export of blender nodes, as well as the MaterialX add-on (if this is accepted).

The platform module is a supporting module, if the render module decides it's needed, we'll make it happen, materialX seems easy enough doubt adding this dep would be much trouble

> @LazyDodo We would eventually need the MaterialX libraries available to use for this, both for automatic export of blender nodes, as well as the MaterialX add-on (if this is accepted). The platform module is a supporting module, if the render module decides it's needed, we'll make it happen, materialX *seems* easy enough doubt adding this dep would be much trouble

Ray molenkamp commented

2022-09-08 18:21:15 +02:00

Removed subscriber: @ray-1