Delegates
Delegates is a fancy word for 'renderer'. Easy, done.
But I've made this wiki page now, so I may as well go into a little more depth, so we can cover some more terminology.
Scene vs rendering
In non-usd land, rendering non-trivial stuff usually involves converting your stuff into a format that the renderer prefers. Sometimes this is done magically for you, but often cg people want to control this processs, so will go through a step to convert their .hip to .ifd for mantra per frame, or .ass for arnold, .rib for renderman etc. So to be clear, we're going from a proprietary format (.hip), to another renderer proprietary format (.ifd), and finally to pixels.
Hydra and delegates
USD from the early days was always thinking of ways to get stuff to pixels quickly, be it for a realtime viewport in usdview, or a slower but higher quality offline renderer. It's designed in such a way that the usd files on disk can be 'baked out' quickly into a generic format, then provide an easy way for render developers to ingest that 'baked' result and generate pixels. This middleware bit, the talking to usd files on one end, and talking to renderers at the other end, is called Hydra.
When a renderer can talk to Hydra, it's called a delegate, ie, it 'entrusts responsibility' to that particular renderer to take the baked USD result and do useful things with it.
What's interesting is the promise of one interface to rule them all; you can have a realtime hydra delegate for fast viewport manipulation, swap it to a renderman delegate for high quality renders still in the viewport, and also use the same mechanism to write frames to disk.
'So what?' you say, 'we have redshift working in houdini, arnold in houdini, vray etc, how is this different?'. The answer is that all those things exist in Houdini. The important difference for USD and delegates is that this renderer support exists in the file format, not in the DCC. This means that in the future the Redshift devs won't have to write seperate Redshift plugins for Houdini/Maya/Max/Katana/C4D, they just target Hydra, and the rest should take care of itself. In reality there's a few things missing (the API for Hydra and lights is being actively developed), but the end goal is there.
The Lops viewport is built on Hydra, and comes with 2 delegates, HoudiniGL (a thin wrapper around Houdini's standard viewport code that can talk to Hydra), and Karma. If you're on windows you'll also have Storm (Pixars realtime delegate) and prman (a placeholder for renderman support if you get renderman). There's delegates for 3Delight, Redshift, Octane, Cycles, a pathtracer from ATI, and several experimental ones on the horizon. Katana and Nuke now also have viewports that work with Hydra, and of course the standalone tool UsdView is also built around Hydra.
Hype vs reality
Right now, in May 2021, the performance and reliability of most Hydra delegates are not 100%. Even the relatively simple and stable HoudiniGL delegate for Lops can get crashy and glitchy, Karma is better, Renderman is pretty good, others are in various levels of stability.
Stability is one issue, supported features is another. Hydra delegates can choose to support as much or as little of the USD features as they're capable of, which makes sense; you don't expect a realtime viewport to do multibounce diffuse through volumes, nor would you expect a high quality offline renderer to run at 60fps. An example Hydra delegate built around Intel's tracing codebase 'embree' only does domelight shadows, nothing else. The Cycles render delegate currently doesn't support rendertime subdivision. HoudiniGL doesn't do primvar colours.
That said, it's all rapidly advancing, and the promise of a unified rendering interface that works not just within Lops, but within other dccs, as well as just standalone direct to the renderers, is pretty cool.
It's also worth pointing out that a delegate doesn't have to be exclusively for rendering; in theory a delegate might just be a spreadsheet viewer for the prims and their attributes, or a diagnostics generator.
prev: UsdGuide12 this: UsdGuide13 next: UsdGuide14 main menu: UsdGuide