Hello all, I am looking to encode wrinkle maps on a mesh. For these I have an array of faces indices and then an int and a float per face. These arrays are very sparse, on a mesh of 100k faces, I might have 100 maps each affecting only a few hundred of those faces.
I really like how I can encode the selection of faces in a geom subset ( even with a nice family name to signal what they are), but then I dont see an elegant place to store the two additional attributes.
Alternatively, I could create 3 x 100 primvars for all the faces, and if I index these, I get 6 x 100 primvars, which seems overkill to store for all the faces on the mesh.
Does anyone have any suggestions on how I can implement this elegantly? ( something along the lines of a primvar on a geomsubset would be great).
For now I am going with subset.GetPrim().CreateAttribute. Since this is just blind data only for our pipeline, think this will work. The usd looks nice and passes validation I believe.
If you are going to read usd in a custom way (even by passing Hydra for rendering), then you can probably just go with custom attributes ( pairs of attributes, one for the indices and one for the values, like you’d have on the GeomSubSet prim ).
If you do need them as primvars and want Hydra and other delegates to handle it, then you might have to use proper length, for the right interpolation (vertex or facevarying or whatever else). And if you do need to provide sparse values, quite often in this case (and for wrinkles actually in our case), we might end up with textures and different mapids (with different resolution for the maps, if we don’t need all the details everywhere).
The only concern I’d have with GeomSubsets is that some delegate can read it, and split the incoming mesh into smaller prims in the renderer, so in a way, if it is blinddata just for your situation, you are going to affect other delegates.
But I don’t have the full picture, so I’m only providing my 2c
We have had some discussions about promoting exactly what you are doing, @koen, for the reasons you mention - it can improve not just sparseness, but also potentially dirtiness propagation for animated/authored values. And anyone who’s been watching the dev branch will note that GeomSubset recently gained the ability to encode points as well as faces, which increases the mesh primvars we could encode this way from just uniform to also potentially vertex and varying.
@paoloemilioselva , I think we could and would need to really specify what the expected renderer/consumer merging behavior of sparse Subset overrides would be, so that all delegates would produce consistent results regardless of whether they split the mesh into individual sub-meshes. There’s also been call to make GeomSubset Imageable so that we could specify visibility on it… though that is not well defined for any element type other than “face”.
So, not a small undertaking, and has not really been a priority for Pixar. But I think the potential is there, if someone is looking to champion it
