USD Properties and Renderers/Render Delegates

Community USD
1

Hi USD Developers and Users,

We/I am relatively new to USD (please forgive what might be a noob question here). After reading most, if not all, of the USD introduction documentation, I am still unclear about how USD Properties, in particular Renderer Settings and USD PrimVars, are supposed to drive supporting Renderers/Render delegates.

I thought the whole point of USD is to have one universal scene description definition that works the same in all supporting DCCs and Renderers/Render Delegates. It is not clear to me how this is supposed to exactly work, especially for Renders/Render Delegates.

Is there a set of (generic/common) USD Properties/PrimVars for rendering that Renderers/Renderer Delegates are supposed to translate into their native Renderer options, attributes, settings, and etc. (either directly or through an intermediate USD translation first)? If that is not the case, are we (USD users/clients) supposed to put matching Render Settings and PrimVars for each Renderer/Render Delegate we plan to or might use? If the answer is the later, this appears to me to flying in the face of the whole point of USD. If it is the former, is 1:1 parity supposed to be expected or should we expect small to even drastic visual differences between Renderers/Render Delegates.

Any insight into how this is all supposed to work (I probably overlooked some section of the documentation) and how it works in practice would be much appreciated.

Kind regards,

Ryan Heniser

Senior (Shading/Rendering) Cinematics Technical Director II
Blizzard Entertainment

2

The documentation to start with is here.

https://openusd.org/docs/api/usd_render_page_front.html

As you can see at the bottom of the page the RenderSettings are not too exciting, and within the context of a DCC you’ll not really encounter them when using a Hydra render delegate, the DCC will have already set things up.

Prims that you’ll want to render are gprims, prims with geometry, and you can read about them here.

https://openusd.org/dev/api/class_usd_geom_gprim.html

Hydra itself takes care of traversing the scene graph, looking for things that can be rendered, and marshalling them as rprims - renderable prims, to be used by a renderer.

USD’s materials are expected to be reproducible by different renderers. This material is very much like the typical basic material you find in game engines, substance painter, and so on.

https://openusd.org/release/spec_usdpreviewsurface.html

If you are using common DCCs, and a renderer that has a Hydra delegate (most off the shelf renderers have a Hydra delegate at this point), then the mechanics of using Hydra as a viewport renderer for USD should be seamless.

Is this the information you are looking for?

3

Hey Ryan, nice to see you here!

To add to what Nick said, OpenUSD and Hydra are (want to become! we all want that!) the common infrastructure for “describing scenes and send them to renderers”.

What comes with the main git repo could be considered the “reference” implementation, for how things should be implemented by everyone else writing delegates and renderers for example.

But there are obviously various levels to this, and not everything might be responding in the same way or even consider all the features (yet?), today.

Depending on what you need to do, some plugins or DCCs are more advanced than others, or have worked around some existing limitations in their specific ways.

4

Hi Ryan,

I know this is an area Pixar has been and continues to work on, but for several years, Houdini has basically taken the approach of bundling up the attributes on the RenderSettings/RenderProduct/RenderVar prims, and passing them as a gaint dictionary to the render delegate through the SetRenderSetting API. See HDK: USD Hydra: Customizing For Houdini for details about how Houdini encodes all this information.

Keep in mind this is outside of any standard, and I believe only Houdini behaves this way. But also as far as I know, Houdini is the only application that makes all of this information available to the render delegate, so a lot of delegates have chosen to support this quasi-standard in order to integrate with Solaris.

1 Like
5

First, let me thank you gentlemen for taking the time to give such thorough replies—​They are much appreciated.

=========================================
Hi Nick,

It is good to run into you here! Hope all is going well with you at Pixar.

Thank you for the links and overviews—It caught an oversight on my part. I did have a cursory read of the UsdRender and UsdGeom documentation, during my first pass through the documentation. But I did somehow overlook an adequately deep dive into the Hydra (2.0) documentation. Thank you for pointing me to it. It is probably going to take me a few reads to get my head completely around it though.

Yeah, I have had a good read of the UsdPreviewSurface specification/documentation, which I found well thought out.

In general, the parts of the documentation you have pointed out are definitely helpful.

Perhaps I was too general in my initial inquiry (or perhaps I don’t have a good enough grasp of USD to ask inquiry well). Maybe a more concrete problem statement will help to clarity and narrow my inquiry.

At Blizzard (Cinematics), I inherited a pipeline with two renderers: RenderMan and Redshift. Both renderers are PBR path tracers, which will have a number of overlapping renderer settings/options and renderer object settings/attributes. For example, both PBR path tracing renderers have an object setting/attribute to enable/disable visible to camera rays. I guess I naively (or idealistically) thought I would be able create one UsdGeomPrimvar that could drive camera rays enable/disable in both renderers, like so (please forgive the following crude Python)


#  A generic path tracing prmvar for camera rays
model = stage.DefinePrim("/world/group/model", "Xform")
model.SetMetadata('kind', 'component')
primvar = UsdGeom.PrimvarsAPI(model.GetPrim()).CreatePrimvar('visibility:camera', Sdf.ValueTypeNames.Int).Set(0)

# Would get converted to UsdRi when rendering with PRMan
riStatements = UsdRi.StatementsAPI.Apply(model.GetPrim())
attr = riStatements.CreateRiAttribute("camera", "int", "visibility").Set(0)

# Would get converted to UsdRedshift (a USD Redshift Schemas I just made up, as I don't think Redshift has one currently) when rendering with Redshift
redshiiftStatements = UsdRedshift.StatementsAPI.Apply(model.GetPrim())
attr = redshiftStatements.CreateAttribute("primary_ray", "int", "visible").Set(0)

Hopefully, that clarifies and narrows my inquiry.

=========================================
Hi Paolo,

It is nice to see you here too! Hope the winter is not too bad for you in Wellington (the winter wind there was scary at times).

Yeah, I definitely need to spend more quality time with the Hydra docs and source code—it appears to be the missing piece of the puzzle for me.

Yeah, I agree with you. It appears that some plugins and DCCs are more advanced and adhere to the reference implementation more than others. I guess that is to be expected at this time, as many developers are still relatively new to USD—Me included!

It will just take some time for us all to sort it out and converge to the specification.

Thank you for your additional comments and good luck on your new endeavor.

=========================================
Hi Mark,

Thank you for sharing your insight. We are currently using Katana. However, we did meet with our SESI representatives about Solaris and Karma. I must say we were impressed. Solaris has made some great progress with USD. Once we set up a basic USD pipeline in Katana. we are definitely going to have a deeper look at Solaris and Karama. I have read and bookmarked that HDK page for future reference. Thank you!

Kind regards,

Ryan Heniser

Senior (Shading/Rendering) Cinematics Technical Director II
Blizzard Entertainment

6

Hey Ryan!

UsdRender has a set of common attributes (e.g. disableMotionBlur, disableDepthOfField) that we expect all renderers to implement/translate, but it’s definitely not comprehensive.

Since these visibility modes are a relatively common feature, if you want to take a try at standardization (e.g. of a UsdGeom API schema), we have GitHub - PixarAnimationStudios/OpenUSD-proposals: Share and collaborate on proposals for the advancement of USD as a forum for coming to consensus on those.

The local option is to procedurally expand/translate this kind of attribute in Hydra. If you’re using Hydra, we have a system called “scene index plugins” where you can register a data filter that gets the option to rewrite scene data as it goes by, customizable per application or per renderer. You could use one of these scene index plugins to rewrite the single visibility attribute from the asset into either an Ri or a Redshift attribute, or both. If you’re looking into this approach, I’d take a look at:
Universal Scene Description: Hydra 2.0 Getting Started Guide for starters. If you have further scene index questions, though, the forum is a great place to ask!

Hope that gives you some leads.
Tom