A out the Tangent Animation meeting, a proper place to talk about it

[JuanGea]

Sorry, I haven’t notice that I was answering in the meetings archive, here goes my comment about it so we can have a talk in a more proper place.

@sybren

Tangent have also created a Hydra Delegate for Cycles, making it possible to directly render USD files with Cycles without having to convert all data to Blender-native data first. Brecht indicated that he is open to including such a system with Cycles, even though it probably would not be used by Blender itself.

Regarding this… could be interesting to have this inside Blender, to avoid Blender cluttering the system ram with a big scene.
Right now we have different duplicates of the scene in memory when a render is done AFAIK, and that’s why the ram usage of Blender sometimes is a bit in the clouds:

1.- The blender scene itself, several Gb
2.- the experted scene to Cycles, more or less the same amount, may be a bit less because some optimizations
3.- the scene in GPU memory, unavoidable obviously and nothing wrong with that.

But the point 1 and 2 elevates the RAM requirements to be able to render some scenes, because a big scene that requires around 20Gb of RAM to render it actually needs around 40Gb of RAM because Blender keeps eating narly the same RAM when Cycles renders it.

Maybe using that Hydra delegate (if I understood it correctly) we can render USD’s ready to render withoutthe need of Blender loading in the scene memory that information, freeing a lot of RAM for Cycles.

@sybren

Finally we agreed that such meetings can be fruitful to have on a regular basis in the future. Sybren noted that most discussions should be had in the open, especially when it comes to code reviews and decisionmaking, but that of course a regular voice/video chat can have its benefits as well.

Great news

[SpookyDoom]

@sybren

Finally we agreed that such meetings can be fruitful to have on a regular basis in the future. Sybren noted that most discussions should be had in the open, especially when it comes to code reviews and decisionmaking, but that of course a regular voice/video chat can have its benefits as well.

That is great news, indeed. Would be cool to maybe have some people from game development for input as well.

[bsavery]

Moving post to this thread instead of meeting notes:

We (AMD) are working on some similar stuff. Simply put:
An addon that allows USD / Hydra rendering as a Render Engine, as well as a nodegraph for USD scene composition.

So for example here is the “default” mode of what the node graph would be, reads (exports) the USD data and passes to Hydra for rendering (using the Radeon Pro Render Hydra delegate in this case):

However this can be more complicated of course:

to reference in USD files.

Other options for nodes we have currently are filtering USD paths, writing out USD files, etc. The basic Idea you can think of as inspired by Houdini 18 Solaris: https://vimeo.com/351433429 .

So this of course uses USD libraries that we would package with the addon, including them with Blender would of course be easier. As well as if this addon would be useful for the entire world (in that it would enable other renderers to easily provide USD Hydra delegates, 3Delight, Arnold, etc) we would gladly share this work.

[JuanGea]

This could be interesting as a C++ patch rather than an addon, for performance reasons I think, but the idea seems interesting.
The problem is that in that case, correct me if I’m wrong, you cannot see the USD in the viewport prior to render, or work with it, am I right?

Anyways, interesting idea

[bsavery]

We currently use the native blender USD import export (in C++). All else is basically just moving USD data pointers around in Python (using USD python bindings). This is no slower. In fact, I would claim this is faster than a normal renderer addon since it’s not parsing geometry data in python.

The viewport part is where the Hydra Render Engine comes in. it works like any other render engine addon but uses the data from the USD graph, not necessarily only what is in Blender.

[statixvfx]

Please please cross pollinate these ideas. USD scene graph and management in Blender with a hydra viewport will put blender smack bang in the middle of modern VFX pipes.

A USD graph would solve/help with scaling shot and sequence complexity, something blender currently doesnt do very well.

This is very exciting!

[MartinBailly]

yeah i think it’s time for blender to have a render/scene management nodegraph as part of the everything node project ! ( a little rightclickselect proposal : DBfbbc). Not just for usd but for alembic and linked data too.

[galenbeals]

Hey Brian, This looks so cool! I’ve been working in Solaris lately i. I still prefer the seems fine for the most part. I still like the USD implementation in Katana better hough. We had the guys from Isotropicx come to our work and do a demo of Clarisse. Their node graph looks even better in my opinion. Still, I would definitely see this expanded.

Seeing this makes me wonder if there any plans for using this like a multi-shot setup/lighting environment? With collections, overrides, passes/layers, etc like in the other systems (Solaris/Katana/Clarisse)? That would be really great. I could imagine a lighting node that just imports your lights from blender, converts them to USD and lets you do overrides per shot similar to the Gaffer3 node in Katana.

Another question I have is how are materials dealt with once the blender scene is loaded into the USD environment? Do you need to re-assign the blender materials or are blender materials and assignment converted to MaterialX or something? Or do you simply have access to the material groups and need to make all new materials for the specific delegate? Materials within USD are a bit mysterious to me at the moment since all the different implementations seem to do things differently.

Thanks!

[galenbeals]

Also, I thought I would mention in case any of the other developers are looking at this: Cycles Render delegate is really exciting but there should really be an Eevee Hydra delegate too. If you think about it, there are a LOT of studios looking into or producing content for TV/Sreaming with Unreal engine as their renderer. I think an Eevee delegate would be even more desirable as they could just render out of whatever USD application they desired.

I would even bet there would be more studios who would be more interested in using Eevee in their productions rather than Cycles since Cycles is competing against the likes of RenderMan, Arnold, Vray, etc. but Eevee’s only competitors are Unreal and Unity.

I think it could also be a big boost for Blender and maybe even bring in developers from other studios looking to add advanced features to Eevee.

Just a thought.

[bsavery]

@galenbeals

Hey Brian, This looks so cool! I’ve been working in Solaris lately i. I still prefer the seems fine for the most part. I still like the USD implementation in Katana better hough. We had the guys from Isotropicx come to our work and do a demo of Clarisse. Their node graph looks even better in my opinion. Still, I would definitely see this expanded.

Can you expand a bit on what you find better / worse about the various node graph or USD integrations?

Seeing this makes me wonder if there any plans for using this like a multi-shot setup/lighting environment? With collections, overrides, passes/layers, etc like in the other systems (Solaris/Katana/Clarisse)? That would be really great. I could imagine a lighting node that just imports your lights from blender, converts them to USD and lets you do overrides per shot similar to the Gaffer3 node in Katana.

This is exactly how we intend it to be used.

Another question I have is how are materials dealt with once the blender scene is loaded into the USD environment? Do you need to re-assign the blender materials or are blender materials and assignment converted to MaterialX or something? Or do you simply have access to the material groups and need to make all new materials for the specific delegate? Materials within USD are a bit mysterious to me at the moment since all the different implementations seem to do things differently.

Materials are an interesting question. There are a few options. USDShade is a way to specify material networks directly in USD. This is fairly trivial to translate a set of blender material nodes into USDShade. However, once in there the render delegate has to know how to use say a “PrincipledBSDF” or any of the other nodes that in blender which is specified in the USDShade network. This obviously would only work with a cycles Hydra delegate. There is also OSL implementations of all the cycles nodes but that would only work on a renderer that can use OSL…

So to really make this work correctly we’d need to take the cycles shader network and put it into something generic, as you guessed, MaterialX. We could either try to translate Blender nodes into standard materialX nodes (they have an extensive library) or only specify that users should use materialX nodes with this. TBD what approach.

[statixvfx]

Re: materials. Wouldn’t it make sense to embrace materialX/OSL completely for something like this ? That way it would be no ambiguity as to what it supports. And for something like ProRender it becomes obvious what it supports. (as opposed to the functions with somewhat blender/cycles compatibility)

Adding some thoughts after having used Gaffer and Solaris. I feel Gaffer is a little bit easier to use than Solaris, probably due to fewer nodes and clearer functions. And the fact that the material graph can exist in the same network as the USD graph is a big plus. Solaris’s context switching between USD, SOPs, COPs and MATs are a bit annoying from a readability pov. Solaris is a beast and extremely well thought out, but perhaps a bit too over-engineered in some places. At least for individual users and small teams.

Gaffer has also embraced OSL as a general data manipulation framework, that works on both images and geometry. So mixing in OSL to process data inside a USD graph is really useful. In Houdini/Solaris you would use a SOP node but as nothing like that exists in Blender, perhaps OSL could be a useful tool.

[bsavery]

@statixvfx

Re: materials. Wouldn’t it make sense to embrace materialX/OSL completely for something like this ? That way it would be no ambiguity as to what it supports. And for something like ProRender it becomes obvious what it supports. (as opposed to the functions with somewhat blender/cycles compatibility)

That’s the direction we’re leaning. However of course you can get the OSL from any cycles node network… so that makes it somewhat more clear.

[galenbeals]

Deleted. Meant to be a PM.

[Bobo_The_Imp]

@bsavery

An addon that allows USD / Hydra rendering as a Render Engine, as well as a nodegraph for USD scene composition.

Would this addon be a paid addon or free, out of curiosity. Either way I’m overjoyed knowing this is coming to blender.

[statixvfx]

200% agree with amotarzi

[bsavery]

Hey Guys / Gals

I’m sure the Tangent folks are excited to hear that. So are we. What I’ve seen they done some awesome work improving the Blender USD export and the hydra delegate.

We’ve been working hard on our “USD tools and Hydra renderer” project as well. We’ll have more to show in a few weeks around virtual SIGGRAPH and when ready will ask for select studios to try out. The general story is:

1. Have a Hydra render engine inside Blender. This allows rendering Blender data though USD with any hydra render delegate you have installed (PRMan, RPR, Hydra GL, etc)
2. USD composition graph for composing complex scenes. This can be used with render engine or to export scene files in USD.

More to come in a few weeks!

[statixvfx]

Hi Bryan,

Did you guys get anywhere with the USD graph in Blender for siggraph ?

[makizar]

There seems to be new developper activity on this!

Cycles Hydra Render Delegate
T96731

Hopefully once it’s implemented someone can find some time to look into memory optimizations.

[JuanGea]

I wonder if once cycles can be a Hydra delegate that could help to make Blender accept other Hydra delegates, that could be very interesting