This has been discussed just a bit when it came out more than 2 years ago, now Houdini, Katana, and some others, are making this their core, so I was wondering why the BI didn’t implement it in 2.8?
4 Likes
It’s a scene transfer format, not a “core”. Houdini of course doesn’t use USD as their internal scene graph manager. They just added option to import and export USD in the latest version. Think of it as something similar to alembic.
4 Likes
Their hands were probably tied with Eevee and overhauling Blender into OpenGL 3.3. Blender 2.8 was already a big enough jump. Give them enough support and let’s hope that we get bigger jumps in the future.
3 Likes
Hydra, a real-time rendering engine, is part of USD, USD is much more than a transfer format, its what drives their proprietary animation software, I saw a demo where 120 M polygons were rendered in real time at 60 fps on a Quadro, and it loads incredibly fast, and Houdini wont support it until 18 as far as I know, no support in it for USD yet!
That’s what I dont get, USD is already there, it only need to be implemented, while Eevee needs to be developed, and USD is Apache compliant!
That’s probably a FOSS thing. It is much more fun to implement cool stuff from the ground up, than to just wire some lib into some app. Even if Blender Foundation has hired a core team of paid developers now I doubt salaries will be top notch industry rates. But developer skillsets are. Make them do stuff they don’t like … they can have that very thing in any big corporation’s IT department, PLUS a lot of money to make them forget their frustration.
We as users just have to accept that I guess, and appreciate the random cool stuff the devs crank out nowadays. 
1 Like
You can compile it and add it to Houdini, i have seen it working.
In regards to exchange formats, i really don’t understand why these are not higher priorities.
Alembic and OpenVDB support is needed. USD would be awesome. All are openly available, the first 2 integrated in EVERY proprietary industry tool, but they are nowhere to be seen in Blender.
Well, not true, they are there, but they don’t work as they should.
1 Like
OpenVDB doesnt support GPU accelerated rendering. Thats why it is converting to Cycles volume texture- for faster rendering. USD itself requare OpenGL 4.5 none less, while Blender 2.8 must work with older OpenGL 3.6 for compatibility reasons.
Thats why there will be no USD for Blender for a while: Partly because users doesnt have modern enough videocards, and partly because some USD components are much worse than what Blender already have.
1 Like
Hydra requires OGL 4.0, pretty much every graphics cards produced since 2010 supports it, everything else is optional, so far only Multi Draw Indirect requires 4.5.
Bottom of the page
https://graphics.pixar.com/usd/docs/api/hd_page_front.html
It’s not a small task to get ALL BENEFITS like hydra and USD support in blender it can take easy 1 year development. Just USD import / export is a smaller task.
I would expect after 2.8 there will be a progress in this direction.
Its mostly integration, the development is on Pixar’s side, and if this was started 2.5 years ago, Blender would fly right now, just saying!
Heheh, being a bit of a tool here, but still, this set of tools is rock solid, and open source, I think this is something that would benefit Blender immensely, even Katana, an industry standard, is moving toward this technology, again, just saying!
“Only”. 
10 Likes
Laugh as much as you want, its still way less complicated, and way less work, than developing the whole thing, and then implement it, which is exactly what they have to do with Eevee! 
even though blender is FOSS, it doesn’t like to play with other OSS kids, and even when it plays with them is half-assed…
You are confusing several aspects, here.
They recruited the developer of PBR viewport branch to create EEVEE.
Eevee is supposed to be a realtime renderer used to produce movies or produce PBR assets for videogames where hydra’s goal is to be a super viewport to preview movies that will be rendered in Renderman. Hydra does not bake textures of same size than the ones used in an indie game.
USD is a way to manage your alembic data. It requires a satisfying alembic support and datablocks management compatible with that.
Developers gave a look at USD. And they thought that they could bring same benefits to users to create things more compliant to Blender than Maya that would request less efforts to maintain and could evolve with weird Blender ideas like a Grease Pencil object.
You are taking as it would be just a copy/paste. But if you take a look at the time and efforts to have alembic and OpenVDB support in Blender, you can realize that took years and it is constantly improved. Dedicated developer have to follow evolution of format and under what ecosystem of software, format is used, to do what and how (what are crucial feature format to support ?).
Does an USD support would benefit to enough blender users to have a developer focusing only on that during at least 3 years? They judged that the answer was “No !” at start of 2.8 project. They decided to follow another way.
Maybe it was a bad appreciation. The same way, they played with ptex and after a while, people asked for UDIM.
USD and Blender are evolving. Situation may change in future.
But maybe, you will be fine with Eevee and overrides and forget USD in 2 years.
1 Like
Why do you keep bringing up Eevee? Is it not USD that you want but Hydra instead? Be aware that Hydra does different things than Eevee - unless I’m mistaken, Hydra does not do things like volume effects or AO.
Yes, Pixar developed Hydra as a preview tool, it uses Optix as its base, and quite frankly it looks as good as anything I have seen in Eevee, but 100X faster, so no, I dont think I am confusing things here, Eevee looks great, but not as good as Cycles does, but Hydra looks as good as Eevee!
And of course not it wouldn’t be a copy paste, I have been programming since the 80s, but integrating something is still less work than also developing the tool that needs to be integrated, not to mention that Pixar is know to help out whenever possible!
USD has native support for Alembic, but at its core its not an Alembic data manager, it has its own, much faster format!
Hydra has multiple backends. It sounds as if you are saying Hydra has the quality of its Optix backend and the performance of its OpenGL backend at the same time, which is not the case. The 100x faster claim I guess is also not based on a real world comparison.
Just as an anecdote, we tested OpenSubdiv as used in Hydra on some high-poly triangle meshes and found it to be 4x slower than our own subdivision surfaces. Reported it to Pixar and they were aware of the limitation but it hadn’t been a priority for them to fix it. Performance is relative.
10 Likes
Hello Brecht
The demo I saw was on Katana, a full scene of around 21M polys with about 6 characters, it loaded in a few seconds and played at its 24FPS speed at 4K on a Quadro M6000, a 2000$ card, without a glitch, and the quality was on par with Eevee IMHO!
My point here is that USD and Hydra are open source, it is heavily developed by some of the best programmers in the business, and it is part of the pipeline of the most acclaimed 3D artists on the planet, now, it is becoming part of more and more of some of the best 3D software out there, like Katana, Houdini, and so on, as a previz tool yes, but then again, no large studios would uses Eevee as a final render engine either!
My initial question here was to understand why this wasn’t considered for 2.8, I think it is a legitimate question, but again, anytime someone questions decisions made by the BI, feathers are ruffled, it wasn’t my intention, my intention here was to have a dialogue, nothing else!
As far as I know no major software outside Pixar is adopting Hydra as their main viewport, rather it is integrated in a way that assets can be viewed in it in addition to the main viewport, typically for studios that adopt USD deeply in their pipeline.
I wasn’t part of the initial decisions for the 2.8 viewport, but can think of a few reasons:
- Development started before Hydra was released.
- EEVEE is aimed at final renders as well as previews, which is not in the design goals of Hydra.
- Hydra does not support many of the features needed by the Blender viewport. It was not designed for mesh editing, texture painting, sculpting, etc.
- EEVEE is compatible with Cycles’s shading nodes system, so assets can be shared easily between them.
- Performance would be worse in some ways by having to translate from Blender to Hydra data structures all the time.
- Hydra requires dropping support for more graphics cards than we do now, and will likely continue to require the latest hardware as it evolves. This is ok for film production, but we also want Blender to run on e.g. Intel graphics in laptops.
- The viewport is a critical part of Blender that touches many areas, and cooperating with another company adds a lot of overhead every time we want to make non-trivial changes. It is quite different than supporting file I/O for a common format.
8 Likes