That’s what my comment about Point3D was based on,starting to dig into the docs—yeah I saw the Point4d as well, but what we need is really a Point[N]D generalized object to hold additional attributes, or a way to match data between the data structures.
One thought of a “hack” way to do it was it could be multiple PointClouds—since my end product is getting composed back together outside of Rhino anyway. We could sample the cloud for actual locations to get cloud 1, then query the associated normals (and encode that resulting list of “points” of nX, nY, nZ data, and then do the same with color.
Then we’d read the PointCloudLocation[x], PointCloudNormal[x] and PointCloudColor[x] values and put them into the csv or Ply format output file:
CloudCompare’s ply header is:
ply
format ascii 1.0
comment Author: CloudCompare (TELECOM PARISTECH/EDF R&D)
obj_info Generated by CloudCompare!
element vertex 676336
property float x
property float y
property float z
property uchar red
property uchar green
property uchar blue
property float nx
property float ny
property float nz
property float scalar_curvature
end_header
And the subsequent lines are space-delimited, so it’d be super easy to compose that format…
… which you could then have Rhino “import” as a new object I suppose X-)