Hey y’all…
Wanted to tease a new project we at AMD are working on. Namely USD / Hydra support inside of Blender. Right now, you can import and export data via USD in Blender. However, we want to really enhance this behavior with adding some new functionality via an addon.
So simply put this addon brings USD Hydra support to Blender offering a few main features:
Ability to render fast viewports via any number of Hydra render delegates. We include Hydra’s GL renderer, and Radeon ProRender, but pretty much every major renderer out there (Arnold, Redshift, etc) have one that should work.
As a side note to this, Renderers don’t need to write custom to adapt to Blender! One thing I’ve noted in my various adventures writing rendering plugins to Blender is we’re all doing the same thing. Having USD as the abstraction layer removes having to export data from Blender for each renderer.
Ability to reference external USD files into the stream without loading data into blender.
Assemble USD files in a nodegraph and share assemblies with other software
Export Materials via MaterialX (work in progress)
You can read a bit more about the plan here:
But for now here’s a demo of the viewport in action!
I haven’t found other explanations about USD very helpful in the past, probably I was not the target audience. So what is this ? how is a standardized scene structure related to rendering ? What is it used for ? data interchange ? something else ?
Okay. But how ? Is there an exploded view of a USD workflow somewhere that I could watch ? The thing is I don’t understand the need : for instance I can assemble a scene with alembics coming from other software already, how is this different ?
A common standardized API for data interchange and interfacing with renderers that would work with any and all renderers that support the API.
It doesn’t matter then if say redshift is interested in supporting blender or not, if they have written support for USD/hydra it will just work.
It won’t matter if autodesk wants to support data interchange with blender or anything else. It’s a standardized interface for it by the industry i.e. the users. As long as properly supported and kept up to date on blenders side, it should just work™.
Oh alright I think I understand ! When you say data you mean things renderers deal with such as triangles, curves, volumes…? and how would a user render out a Blender scene in Redshift ? does the user have to export the scene as USD and import it in Redshift ? or can they just stay and do it all in Blender ? is that what a render “delegate” is ?
TL;DR as I understand it: with respect to renderers rather than having to specifically write a plugin for blenders specific API, maya specific API or whatever else, they write a plugin for the USD’s hydra instead and it will work with any application that supports the hydra delegates.
As a scene format you save or export(depending on how its supported) into USD and load or import(again depending on how the application supports it) into the other package.
The most important thing about this is that it is standardization that isn’t under the direct control of any one third party vendor such as autodesk or foundry or whatever, but genuinely defined by the graphics industry. The behemoths of content creation not the DCC software behemoths.
edit: Also worth throwing out there that hydra can potentially be used also for viewports, not just final renderers. So eevee itself could become a hydra delegate, as could cycles.
So just to recap, the end user needs 1.Blender to export to USD or silently make its data structures compatible and 2.a plugin for the renderer of their choice ? and bam, redshift appears in the “render engine” dropdown ? Crazy cool…
I think I can see the implications of an open standard… Thanks for your time explaining all this Felix.
Main purpose of USD is better integration into a professional pipeline - one coud start working on a lookdev in one software and then take it and continue in another.
And Also USD has very specific idea about scene composition that have benefits on it’s own
First with Hydra rendering. @Felix_Kutt described it ok. Once you have data into a USD stream, Hydra is a very fast system for feeding the data into renderers. It’s a bit technical but it’s very efficient at sending the renderer exactly what it needs to know, and what’s changed etc. The other benefit of why Blender users want this, is like he said, with this Blender to Hydra bridge we’ve done, now renderers that support hydra can work in Blender. As someone who has written a few of these (an evidenced by the time it’s taken Arnold and Redshift to come to blender), there’s a lot of work into adapting a renderer to an application, so having Hydra as the middle layer makes it much easier.
For USD in general as a pipeline tool that Blender users want. For sure this is more of a “pro” feature. If you’re happy importing data from other files that’s fine. Blender also has the concept of “linking” other Blender files in. The way I’d describe the workflow we’re building here is this: If you want to “link” in data in a more powerful way, and across applications, USD is a great tool for that. Moreover, if you Link Libraries in a blender file, blender loads all the data in I think, so it’s somewhat less efficient.
To put this in a more concrete example. Let’s say you create a set background in houdini and want to use it in your blender character scene for the background. Normally you’d export an alembic file maybe and import that in. If you go and change the background later you may have to re-import the data.
With USD and this new plugin you can export a USD file from Houdini, reference that in to your Blender scene. Then if you change the background, you’ve set up a little “pipeline” that the changes are automatically picked up. Moreover the background data isn’t loaded into blender at all, just brought into Hydra for rendering.
Again, for simple users, maybe this is unnecessary. But it’s a cool workflow for studios.
So, this makes it possible for addon developers to develop for all DCCs simultaniously without having to deal with licensing problems caused, for example, by GPL, right? They would just write the main addon once and then create separate UIs for Blender, Max and Maya, right? I mean, addons in general not only renderers.
If you’re writing an addon to manipulate USD data inside Blender it would surely fall under GPL.
The future of USD is to make it possible to build a pipeline of 3rd party tools all referencing on USD scene. So you will see 3rd party particle systems that will take in the base USD scene, add the particle sim then export the scene with added particles onto another USD based APP etc etc.
It will mean that 3rd party software developers only have to support USD instead of every single DCC and or file exchange format.
You could effectively build a DCC from individual USD based 3rd party Apps, a USD based modeller passes on the model to a USD based Mograph App passes onto a USD based fluid sim then rendered by a Hydra compatible renderer or sent to your favourite game engine.
It’s obviously more important for studio who builds their own highly specialised pipelines but I think even a single user will benefit from the higher fidelity interoperation between their Apps and we’ll see more specialised 3rd party Apps spring up as a result.
Hmm… perhaps the other way around would be possible. Write a “mixer” app which specializes in displaying the USD scene and plugging into all kinds of DCC apps which can then be controlled from within the mixer app.
It sounds exactly like file referencing in Maya (or indeed linking in Blender). So this is what scene assembly/solaris nodes do ? they describe the scene elements, lights and materials in a renderer-agnostic way and allow for live updating of assets from other points in the pipe ? I can see it.
yes.
Rendering out huge scenes with 20 - 30GB worth of data was the bottleneck back in the day when movies were still rendered in your general DCC.
As you can imagine loading times and overhead from the DCC was massive and the workflow emigrated to tools like Katana and Clarisse which shifted the final scene construction, lighting, shading and rendering into these programs. Referencing files from the disk directly without loading them into RAM necessarily has become the norm and due to its reference/linking workflow it also enables teams to work on huge scenes together with changes getting updated through the network immediately.
It looks like that from user point but technically it is quite different.
When you’re referencing in Maya all data from reference scene is actually loaded into your current maya session. Same way as import (but with some obvious restrictions).
There are lots of problems in that:
You need to reload references manually. If reference scene would have some changes - you need to restart maya, or reload reference to see that changes in your main scene. If you just hit render button (without reloading references) you’ll got render with old data.
It requires a lot of computer resources. Just imagine - you have 30 GB scene. First you’ll need to wait while Maya recreate everything (could take minutes(!)). Everything will be stored in RAM in current maya session + you’ll need another 30 GB copy of that data for renderer to do IPR.
In USD references are actually references. All data updated as soon as it needs to be undated. And if your DCC’s viewport is based on Hydra - all data is loaded directly to viewport by Hydra. No need to recreate everything in DCC just to look what’s inside.
So it is similar but lightyears smarter and more optimized than what Maya does.
Outstanding Brian! The blender community is lucky to have you. Great work, especially for key production pipelines. I’m glad this was done by an external group and not internally among the core devs. Keep up the good work.
