Hydra 2.0 PrimsDirtied question

Community Hydra
1

Hi,

I have a question regarding the new Hydra 2.0 framework.
I have a mesh with a material and an editor that can change some materialX value (for example input:base_color). I do it with

               const pxr::UsdAttribute &attribute = m_stage->GetAttributeAtPath(m_path);
                attribute.Set(value, m_timeCode);

I do receive the _PrimDirtied for the material, with the locator and the new datasourcehandle. But I was expecting the locator to be input:base_color rather than “material”.
As I got the “material” locator, it seems that I’m forced to reparse all the schema and recreate a fresh new material instead of just updating the new value.
Am I doing something wrong ?

Thank you,

Baptiste

1 Like
2

This question is still open for me.
Is there a way inside Hydra to know exactly what changed inside a material ? I don’t think it is possible right now. The locator is something like material//terminals/surface.
But I think looking at the whole graph (HdMaterialSchema) is a bit too expensive. Any idea ? I thought about TfNotice but I don’t know.

3

I believe you’re correct. I don’t believe I’ve seen a way to diff just the specific attributes, so I’ve also similarly done my own diff setup to see what’s changing at a more granular level.

@tomc might be able to provide more information.

4

@dhruvgovil Can I ask you what you do for this specific problem and how do you handle it ?

5

Hey all,

This is an active area of improvement for us. With UsdImagingDelegate it’s difficult because we don’t have dirty bits defined for various data (different terminals, input parameters, etc). In UsdImagingStageSceneIndex, we’ve recently added code to identify which terminal is dirty (e.g. you’ll get dirty “surface” rather than “material”, as you mention). This is to support the fact that at least in Renderman and Storm we don’t support incremental material updates; if a node changes, we need to recompile the whole material. Given that, sending dirty terminal signals is the most efficient way to communicate to the renderer. I had thought we had augmented it to also send a locator for the specific attribute that changed (in addition to the terminal), but maybe that hasn’t landed yet?

The major remaining issue is supporting quick updates of lofted parameters (note that constants folded into compilation can’t be updated quickly, see above). Our latest thinking is that to make it easy to analyze which parameters can be lofted, we take advantage of the “public interface” concept where parameters defined on the material prim (and connected to node parameters) are considered runtime variable and get invalidated as “params” or “params/albedo”, and parameters defined locally on nodes are constant folded into the compiled material and do not get specific invalidation. I’m not sure what the latest scheduling is for that project, but I think it was coming up soon.

UsdImaging code for invalidating specific terminals:

Renderman scene index filter that also does some network analysis:

… hope that helps.
Tom

3 Likes
6

Thanks, Tom. This is really great insight.

7

Maybe it is in the upcoming 25.08 release. I am using 25.05.01 currently. I’ll check the code to see if it could be in the new release ! Thanks for the insight !

Baptiste

8

Hi,
The way I understood the information should be added is, in the scene index that does the invalidation, we should append to the default locator which parameter changed like :

TfToken nameOfTheAttributeThatChanged;

HdDataSourceLocator locator = HdMaterialSchema::GetDefaultLocator().Append(nameOfTheAttributeThatChanged);

Regards,
David

1 Like