Hello,
We seem to have hit an issue with regards to primvars and material dirtying when using Storm (at least in Hydra 2.0).
Suppose we have an Rprim with its primvars, and it uses a certain material. If we change and dirty the material, the primvars it requires/uses might change; however, the Rprim’s Reprs & DrawItems will not necessarily be updated accordingly, leading to the resulting visuals being incorrect.
As an example : suppose the following scene with a mesh and its material (you can ignore the prims that are not under MayaUsdProxyShape_PluginNode)
Suppose that initially, the material does not require nor use the st primvar. When creating the plane’s Reprs and DrawItems, HdStMesh::_PopulateFaceVaryingPrimvars will be called, but the st primvar will be ignored/not be used.
Now suppose we make a change to the material data source of the material prim :
and suppose that this change now does make the material use the st primvar. The plane’s Reprs and DrawItems would need to be updated; however, since nothing was dirtied on the Rprim itself, the Rprim will not be sync’d, and its Reprs and DrawItems won’t be updated, leading to HdStMesh::_PopulateFaceVaryingPrimvars not being called, and the texture coordinates not being populated correctly. An incorrect result could look like this :
instead of this
There are the __dependencies data sources that dirty the primvars data source on the Rprim based on material-related changes; however, these seem to cover the cases where the primvars might actually be changed due to it being composited from the material’s primvars and the Rprim’s primvars, but not the case where the material (and its parameters) itself changes.
Is that the solution, or is there something else I’m missing? For now we use a simple workaround of just sending a dirty notification on all Rprims’ primvars data source.