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

Wed Jan 5 22:05:13 CET 2022

Hi Charles.
So to distill all this down, what you're saying is it might be useful to
have some USD data rendered with Hydra, and the Blender data rendered in
Workbench/EEVEE/Cycles through the Blender pipeline and then merged into a
single viewport?

Or to give a more concrete example, a set imported via USD and drawn with
hydra while an animator is working in Blender and the character he is
working on just doing the Blender render pipeline and then all that
composited to one viewport.

It should be technically possible but I think there would be a few issues
there. Mainly if you have lights in your USD Stage, they wouldn't light
your character unless the lights are duplicated in Blender.  Maybe it
doesn't matter too much for playblast type stuff or doing animation, but
any lighting work it would.

But the part you are describing to bring the USDStage object into the
outliner is similar to what we're doing now in our addon.

On Wed, Jan 5, 2022 at 9:31 AM Charles Wardlaw <cwardlaw at imageworks.com>
wrote:

> 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
>> *************************************
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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/6547b8df/attachment-0001.htm>