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

Wed Jan 5 18:31:05 CET 2022

Hi Brian,

Congratulations on the new addition. :)

At Tangent I had something going like what you're describing, only the goal
was more about viewport display-- there was a new USDStage object type
which could be pathed to a layer (and a prim in that layer) on disk.  It
had outliner extensions that allowed the user to choose variants and enable
/ disable / move prims, etc.

All USDStage object prims were "merged" into a single anonymous stage for
drawing, and I added a Workbench drawing engine to merge the draws into the
main view. This was the most useful for us-- it meant we could pass
environments downstream without having them actually in the files, but we
were still able to playblast for dailies.  It also meant we could quickly
do layouts by duplicating the objects in scene, although I never got the
Gizmos working on the in-memory prims (still don't 100% understand that
API).

Have you given any thought to perhaps adding the regular viewport draw as
well?  Marking objects to defer payloads, saving variants, edit callbacks,
and so on?  USDPrimConstraints, perhaps, so that a character can reference
a transform in a resolved (and depsgraph-evaluated) USDStage object so that
characters can follow edits from upstream department without importing?  As
useful as the Hydra render preview is, not constantly converting animated
characters to USD geometry per frame evaluation would be huge.

I'd also love to discuss how it could be possible to efficiently key
transformations on a USDStage-style object without having to create an
extra transform, leaving the curves in Blender's action block.  For
example, I heard that Omniverse batches changes together on a
frame-by-frame basis for speed through the SDF layer?

And if any of this has already been discussed I apologize-- I'm a recent
addition to the list and still coming off a turkey coma from the holiday. :)
~ C

On Fri, Dec 24, 2021 at 5:50 PM Michael A Kowalski via Bf-usd <
bf-usd at blender.org> wrote:

> Hi Brian,
>
>
>
> Thanks for sharing your ideas!
>
>
>
> I'll provide a detailed response after the holidays, but I'm certainly
> looking forward to discussing your proposal and to working together to
> design and extend the USD import / export APIs.
>
>
>
> Michael
>
>
>
> *From:* Bf-usd <bf-usd-bounces at blender.org> *On Behalf Of *Brian Savery
> via Bf-usd
> *Sent:* Friday, December 24, 2021 11:55 AM
> *To:* bf-usd at blender.org; sybren at blender.org
> *Cc:* Brian Savery <brian.savery at gmail.com>
> *Subject:* Re: [Bf-usd] Bf-usd Digest, Vol 13, Issue 3
>
>
>
> *External email: Use caution opening links or attachments*
>
>
>
> 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
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblender.chat%2Fchannel%2Fpipeline-assets-io-module&data=04%7C01%7Cmakowalski%40nvidia.com%7Cbf7c31eb547d406393c408d9c6fe2e1f%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637759618187965161%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=M%2Frm2My6ret%2FMjFBVJlBh5TO34LbiUAtkRNWOukuf0g%3D&reserved=0>>
> 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
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.blender.org%2FT68933&data=04%7C01%7Cmakowalski%40nvidia.com%7Cbf7c31eb547d406393c408d9c6fe2e1f%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637759618187965161%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=FzWaMT2TAYdeVqHlzsBm5aC3XHow0624RaSNh3vh60k%3D&reserved=0>
> >.
>
>
>
> 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
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.blender.org%2Fpipermail%2Fbf-usd%2Fattachments%2F20211223%2Fa1fda356%2Fattachment-0001.htm&data=04%7C01%7Cmakowalski%40nvidia.com%7Cbf7c31eb547d406393c408d9c6fe2e1f%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637759618187965161%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=pTWhLIniBw34%2BBUF4Oz9Z1%2FMLWNovD4lk9wxEQklwZI%3D&reserved=0>
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> Bf-usd mailing list
> Bf-usd at blender.org
> https://lists.blender.org/mailman/listinfo/bf-usd
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.blender.org%2Fmailman%2Flistinfo%2Fbf-usd&data=04%7C01%7Cmakowalski%40nvidia.com%7Cbf7c31eb547d406393c408d9c6fe2e1f%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637759618187965161%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=CvjcROZ92%2BS3UqCtpOg4q6Z4jbvSfYt8lt%2B6qpAGZr0%3D&reserved=0>
>
>
> ------------------------------
>
> End of Bf-usd Digest, Vol 13, Issue 3
> *************************************
>
>
>
>
> --
>
> brian.savery at gmail.com
> 508-274-8700
> _______________________________________________
> Bf-usd mailing list
> Bf-usd at blender.org
> List details, subscription details or unsubscribe:
> https://lists.blender.org/mailman/listinfo/bf-usd
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-usd/attachments/20220105/c423d655/attachment.htm>