I’ve got some trees that are skeletons + geometry. I want to add leaves with point instancers and need someway to deform the point instances from the skelanimation since i don’t want to have another prim for the point instancer positions. I can only think if you had a prim for the instance points that was skinned to deform from the skelanimation, and then had a relationship between the point instancer and that prim… but i could be way off the mark. Thanks!
Hi @latimerias , and welcome to the forum! That is an awesome use-case, and we have done custom, Katana-only solutions like that in the past. It would be fantastic to be able to express that in USD. The place we are in currently is that generally, unless explicitly called out and planned for, schema features/behaviors in USD do not combine, so what you’re trying to do is not possible.
Once OpenExec has landed (which is still some ways out), you should indeed be able to skin a Points primitive, and connect the PointInstancer’s positions to the Points’ points attribute, and (I think) make a computation that uses the Points’ deformed normals attribute to drive the PointInstancer’s orientations attribute, if needed, though that would be more work.
There could also be a discussion to be had about allowing a PointInstancer itself to be directly skinnable, which might be supportable in Hydra 2.0, but I am just spitballing and there could be good reasons that would be a bad or unsupportable idea!
Thanks for the great response! The OpenExec solution sounds exactly like what I was looking for, but it is my first time hearing about OpenExec so I am wondering how it fits into USD, is there some place to read about it or will that come in the future?
The most information you’ll find about OpenExec currently is in our SIGGRAPH BoF slides from this past August, which just got posted on our “Downloads” page: https://openusd.org/files/BOFSiggraph2023.pdf
2 Likes
I’m not sure how UsdSkel (or something similar) would apply to UsdGeomPointInstancer at a schema level, but at the hydra level we represent UsdSkel just as a computed “points” primvar on the target mesh. This computation is managed by Hydra, and with Storm it’s specifically managed as a compute shader.
We’d need a small-to-medium amount of hydra work to support it, but it would be a pretty natural extension to let hydra compute instancer primvars as well; this would mean you could pass in a computation (some kind of skinning) that would produce a “positions” primvar on your point instancer, and when we draw the point instancer prototypes they would refer to these computed positions to transform themselves, and the computation could be run in a compute shader for GPU-facing render delegates. If it required API changes, I think they’d be pretty minimal; the main thing is to rope hydra instancers into the computation scheduling process.
It would be great for someone to file an Issue for this for tracking, given that we are reasonably confident it’s within the realm of possibility!
I made this ticket
2 Likes