I find myself needing to delete points from a point cloud. Obviously, to do this, I need to remove the per-point data for these points, for example, primvars:displayColor, primvars:st. But how can I identify per-point attributes? I can obviously find primvars with vertex interpolation, but there are non-primvar attributes such as displayOpacity and the interpolation usually isn’t set for Points prims. I can find attributes with the same number of elements as points, but this is fragile. This is complicated by, for example, the proposed GaussiansAPI which has primvars:sphericalHarmonics where the attribute contains up to 15 values per point. Is there any solution apart from just hardwiring the known cases and allowing the user to specify extra ones manually?
Edit: my comment here was me thinking about the default values in the schema, but as Matt correctly points out below you can explicitly do it in the actual authored data. Leaving my comment here for posterity.
———
I don’t think there’s currently any method to do this automatically within the schema .
It would perhaps be a good proposal in itself to allow point attributes to specify their associationship and strides in a way that can be used by tools automatically
If a primvar on a Points primitive is expressing per point data, it should use varying or vertex interpolation metadata. If there are multiple elements per point, it should set the elementSize metadata. An common example of using elementSize is specifying number of weights per point in UsdSkel. Universal Scene Description: Schemas In-Depth
Yes, you’re right. I was getting confused and I think I was thinking of “normal” vs. “primvars:normal”. I could have sworn that displayColor/Oacity had the same thing going on at one time.
Ah good call out Matt, I guess I meant providing that elementSize by default in the schema, which I think the usdGenSchema disallowed when I last tried it? But I’ll try it again and see if maybe it was a bug at the time or an error on my part.
But yes, authors of the data could author elementSize on each attribute at the time of authoring fields
Yes, and apologies I didn’t mention this aspect on the GaussianSplat thread… it’s a recent development to enable most metadata on properties in schemas. The extreme restriction was out of an abundance of initial caution, but now that we need to allow uiHints through, we concluded the caution was no longer warranted.
@jerry.huxtable , it would be useful for UsdGeomPointBased to either enumerate or answer queries about its own Point-Based properties… For example, velocities and accelerations will always be effectively vertex interpolation and thus “point based”; normals, however, have a special (regrettable in hindsight) callout for authoring interpolation, so prim.normals may actually be faceVarying rather than vertex, and thus not (especially for your purposes) strictly “point based”
@spiff Yes, having an API to enumerate over the point-based properties would be useful. I realize that we have to worry about other types of interpolation for UsdGeomPointBased, but my immediate problem is UsdGeomPoints specifically (I’m dealing with point clouds and splats). The same problem would arise with things like Mesh and BasisCurves where we might want to find all the per-face, per-face-vertex or per-segment attributes, so an API for those would also be useful.