Hi McNeel folks, any possibility of having a Point Clouds native/shipped with Grasshopper 1.0? They are much more efficient to display and use when dealing with large data sets, and beginning to be more commonly used with the prevalence of 3D scanning. I’ve written written one that wraps Rhino.Geometry.PointCloud in a GH_PointCloud, which seems to work effectively, but it would be good to see this included from the ground up. Any thoughts?
It’s certainly not going to happen for Grasshopper 1.0, at this point we’re only fixing bugs in that code base, not adding new features.
As for Grasshopper 2.0… maybe? I’m not entirely convinced that adding it as a type is a good idea. Pointclouds in Rhino are primarily a solution to memory/performance problems. It’s true that you can have normal vectors associated with the points, which is not possible using regular points, but that seems like a pretty exotic feature.
Grasshopper already collects all the points it draws per parameter into a single array for display purposes, so there wouldn’t necessarily be any performance increase there. GH2 will also have mechanisms that would allow for individual colours per point.
My reticence is mostly due to the potential confusion this could cause. Either all components which take points or lists of points as inputs must be made aware of the existence of point-clouds (which means a lot of extra work for all developers forever), or users will get confused when a component refuses to accept a point-cloud because it was expecting regular points.
I do agree that GH2 should be able to import point-clouds from Rhino and bake point collections as clouds to Rhino, I’m still on the fence about wrapping PointCloud as a native data type.
2 Likes