Difference between revisions of "UsdGuide13"

From cgwiki
(Created page with "=== 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...")
 
Line 24: Line 24:
  
 
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.
 
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.
 +
 +
 +
----
 +
 +
prev: [[UsdGuide12]] this: [[UsdGuide13]] next: [[UsdGuide14]] <br>
 +
main menu: [[UsdGuide]]

Revision as of 06:36, 16 May 2021

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

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 talkign 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.

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. There's delegates for Renderman, 3Delight, Redshift, Octane. 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. A part of the design of Hydra is 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.



prev: UsdGuide12 this: UsdGuide13 next: UsdGuide14
main menu: UsdGuide