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. Right now, in May 2021, the performance and reliability of most Hydra delegates are not 100%. Katana and Nuke now also have viewports that work with Hydra, and of course the standalone tool UsdView is also built around Hydra. There's delegates for 3Delight, Redshift, Octane, Cycles, a pathtracer from ATI, and several experimental ones on the horizon. If you're on windows you'll also have Storm (Pixars realtime delegate) and prman (a placeholder for renderman support if you get renderman). 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. In reality there's a few things missing (the API for Hydra and lights is being actively developed), but the end goal is there. 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. The important difference for USD and delegates is that this renderer support exists in the file format, not in the DCC. The answer is that all those things exist in Houdini. 'So what?' you say, 'we have redshift working in houdini, arnold in houdini, vray etc, how is this different?'. 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. 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. This middleware bit, the talking to usd files on one end, and talking to renderers at the other end, is called Hydra. 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. 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. So to be clear, we're going from a proprietary format (.hip), to another renderer proprietary format (.ifd), and finally to pixels. 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. In non-usd land, rendering non-trivial stuff usually involves converting your stuff into a format that the renderer prefers. Easy, done.īut 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. Delegates is a fancy word for 'renderer'.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |