[Bf-usd] Bf-usd Digest, Vol 13, Issue 3

Brian Savery brian.savery at gmail.com
Fri Dec 24 17:54:57 CET 2021


Basically the answer is yes, our proposal is that we integrate this "Hydra
addon" directly into Blender to use the internal apis for export, and allow
users to install their own Hydra delegates, which would open up some
flexibility for other renderers.

Our target would be mid - late 2022 timing wise.  But we're looking for
some "blessing" or sync up with BF (and Michael) that this is a good idea
and something you would accept.  Basically a design review.  I don't
foresee any disagreements, but with Materials, we might have different
opinions, and BF should have the final say.


> > Some todo's I see for bringing this into mainline.
> >
> What does "mainline" mean? Do you mean Blender's master branch?
>
> 1.  Aligning with the current import / export USD work that is being done.
> > We currently translate the blender data via python and the USD python
> > binding but obj.  Moving this directly into blender's code where it could
> > use the internal C api would be advantageous.
> >
> It would indeed be advantageous to work together with Michael Kowalski
> (NVIDIA) on this. He's coauthor and maintainer of Blender's USD importer,
> and he's actively working on improvements on both import and export. This
> mailing list, as well as the #pipeline-assets-io-module channel
> <https://blender.chat/channel/pipeline-assets-io-module> on Blender Chat,
> would be good channels to sync up.
>
>
That's fine, I'd ask if we could be included in future meetings on USD.  I
am actually on paternity leave for the next month but can get a design
review meeting so we can start things on our side.


> 2.  Writing a proper scene delegate for Blender's data to Hydra.
> > 3.  Making the MaterialX workflow a bit simpler.  It might/should be
> > possible to just use blender's nodes and translate them at render time to
> > MaterialX nodes.
> > 4.  Integrating the USD data representation in Blender a bit more
> > tightly.  Using the empty objects for each USD prim is a bit awkward.
> >
> How does this relate to the current work on Blender in this area? I'm
> thinking about tasks like T68933: Collections for Import/Export
> <https://developer.blender.org/T68933>.
>

Yeah, so that one sort of addresses why this could be useful in the "USD /
Hydra" and "Nodes" section, this is pretty much exactly what we did (plus
the MaterialX stuff).  But it's unclear to me if the goal here of this task
is to actually handle the deferred loading for rendering or just how
it could happen.

So maybe our proposal could be considered an extension to that task to add
Hydra support and the node tree for manipulating data.  And we would re
write parts to use that work when it's landed.

>
> Cheers,
> Sybren
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.blender.org/pipermail/bf-usd/attachments/20211223/a1fda356/attachment-0001.htm
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> Bf-usd mailing list
> Bf-usd at blender.org
> https://lists.blender.org/mailman/listinfo/bf-usd
>
>
> ------------------------------
>
> End of Bf-usd Digest, Vol 13, Issue 3
> *************************************
>


-- 
brian.savery at gmail.com
508-274-8700
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-usd/attachments/20211224/fb87d69c/attachment.htm>


More information about the Bf-usd mailing list