<div dir="ltr">Hydra integration for renderers is worthy of its own design document. There's many technical challenges: how to translate shaders, how to integrate with the dependency graph for incremental updates in viewport rendering, how Hydra integrates with the render engine API, and so on.<br><br>On the practical side of things for this add-on, it makes sense for us to move to shared libraries for Blender, for reasons besides Hydra. It's a complex change so we haven't prioritized it so far (if we do it for USD we also need to do it for all of USD's dependencies). An API function to convert a depsgraph to USD and provide a pointer also seems reasonable.<br><br><br>By itself, Hydra does not require design for the user workflow or changes to Blender public data structures. The user would not even need to be aware that Hydra is there under the hood, it would just transparently be used for final, viewport and preview renders. Where user workflow comes in is USD node graphs.<div><br></div><div>In the devtalk thread, there is an example node graph that reads a USD file which is then connected to a Render USD via Hydra node, and in that node RPR is selected as the renderer. With a node graph like that, would not have the ability to view the same scene with different engines in different viewports, inspect the resulting scene hierarchy in the outliner, or select/hide/isolate objects in the viewport?<br></div><br>So what I'm proposing is that such a node graph should feed into the Blender scene hierarchy, to support interactive inspection, editing and overrides. It doesn't mean conversion to Blender data structures is always done, just that it is possible.<br><br>On Wed, Aug 12, 2020 at 1:24 AM Brian Savery <<a href="mailto:brian.savery@gmail.com" target="_blank">brian.savery@gmail.com</a>> wrote:<br>><br>> Hi Brecht, et all.<br>><br>> I've been meaning to write up a bit more here (too many projects), but I'd like to give an idea what we (AMD) are working on, because it overlaps a bit with what you lay out in that document.  A lot of what you say would be good to do inside Blender, however we have already done quite a bit of this in an addon! <br>><br>> So basically, our WIP addon is two things:<br>> 1.  A Hydra render addon to blender (just like any other renderer addon) that renders via hydra similar to other renderer plugins to Blender.  We of course include the Radeon ProRender Hydra delegate but you could use this with PRMan Hydra delegate, or Redshift, or Octane, or Arnold etc.  So think of this like a "meta" render addon.  Part of the motivation here actually was because we felt that each render addon to blender is kinda replicating the same code to export data to the renderer and USD Hydra gives a good abstraction layer for this.  <br>><br>> 2.  So the normal way a renderer addon works is to pull data directly from Blender.  We also include a USD Node graph, which allows you to composite USD via references, export data from blender into the USD node graph, filter data etc.  The Hydra render addon would then pull from the nodegraph rather than data directly from blender and get the references etc.  I added some screenshots and discussion here:<br>> <a href="https://devtalk.blender.org/t/a-out-the-tangent-animation-meeting-a-proper-place-to-talk-about-it/13733/3?u=bsavery" target="_blank">https://devtalk.blender.org/t/a-out-the-tangent-animation-meeting-a-proper-place-to-talk-about-it/13733/3?u=bsavery</a><br>><br>> So rather than being a direct property of collections we achieve this in a node graph for assembling the data.  <br>><br>> We're pretty close to sharing something for testing and feedback from users, certainly we are hoping early fall.  In the meantime if there are serious objections or thoughts on this approach we'd like to hear them.<br>><br>> Finally here's a bunch of issues we are hitting so far. <br>><br>> 1.  Distribution.  Blender statically links in USD dll's which is less than idea as we need to include our own then for this.  <br>> 2. Furthermore, it would be ideal to get a pointer to USD data exported from the USD export function rather than exporting our own USD data<br>> 3.  Namespace issues on macOS don't allow us to currently bring in separate USD dlls <br>><br>> Of course IMO this is something that could be even more powerful built into blender, with a built in hydra rendering option.  Perhaps after we get this addon out there that can be visited, but I think we're much closer to getting this out as an addon.<br>><br>> Brian<br>><br>>><br>>><br>>> Hi all,<br>>><br>>> I've written a design doc about how USD might integrate more closely in<br>>> Blender, and how that would relate to collections and other Blender data<br>>> structures.<br>>> <a href="https://developer.blender.org/T68933" target="_blank">https://developer.blender.org/T68933</a><br>>><br>>> It's only a rough proposal at this point, and we'll discuss this more<br>>> internally as well. But it would be great to hear feedback and see if the<br>>> overall direction makes sense to others.<br>>><br>>> Regards,<br>>> Brecht.<br>>><br>> --<br>> Bf-usd mailing list<br>> <a href="mailto:Bf-usd@blender.org" target="_blank">Bf-usd@blender.org</a><br>> <a href="https://lists.blender.org/mailman/listinfo/bf-usd" target="_blank">https://lists.blender.org/mailman/listinfo/bf-usd</a></div>