USD Hydra Render Delegate

14 Jun 2020


What is USD? Pixar's Universal Scene Description (USD). Read more about it here. The following short descriptions are taken from there.


Hydra is the imaging framework that ships as part of the USD distribution.


The USD front-end to Hydra is used in usdview and the third-party plugins included with the USD distribution, and is meant to provide a "ground truth" geometry rendering of any scene composed of prims conforming to the UsdGeom schemas. It also provides fast preview and animation streaming for USD scenes.

Click on the image above to get redirected to a YouTube video which shows RenderMan being used through Hydra (within usdview).

3rd Party Renderers

The distribution also ships with a simple Embree-based path tracer to serve as an example for creating more backends.

Lets just say that compiling the USD source code and it's dependencies from scratch isn't that easy, but feel free to follow the Advanced Build Configuration and find out for yourself. Hint: Try without Python first, if that works add Python support, so you end up at least with usdview. After that try adding Embree.

I started writing a skeleton for any renderer, which means that there is a library, which compiles and links against USD, and some standalone executable for a minimal hydra application, as described here (for Embree), except that I took out all Embree related code and replaced it by PBRT:

USDView and other renderers like PBRT and Arnold.

I also managed to compile the Arnold version of their USD components as you can see in the screenshot above, but currently it just core dumps on my Ubuntu machine as soon as you try to render something ...

Let's see if I find time in the future to keep working on this. I would like to build such a bridge to my own Rust based PBRT implementation, rs-pbrt. The first step would be to use the C++ code and fill in the bits and pieces for the skeleton to actually render something using the PBRT API (which might has to be adjusted slightly to do that). After that I would do the same adjustments for the Rust version of the API and use foreign function interfaces (FFI) to make C++ and Rust talk to each other. Maybe safer_ffi can help with that?