So it is not a secret that Grasshopper and Rhino is very slow when it comes to processing a lot of points.
I usually work with huge survey terrain information and any adjustments to original point cloud with millions of points is just doesn’t work.
I assume I am not the only one.
Do you have any strategies you have been using?
I usually end up projecting smaller grid of points and reconstruct simple mesh to be able to work.
Maybe there is away to make data processing in batches?
Also does multi threaded GH2 will be able to solve this problem?
I don’t know what operations you are performing on the points, but if it’s nothing too difficult it may make more sense to add a pointcloud type to Grasshopper to operate on. This will drastically reduce overhead when storing and sharing the point data.
If that’s not possible, then indeed chopping it into distinct buckets sounds like the way to go, but there’s going to be some custom development involved to iterate over all these buckets automatically.
Ehh, yes and no. Mostly no.
The data will be stored more efficiently in GH2 because the individual points don’t have to be wrapped up in special point data classes. So the pointcloud would just be represented as a single array of Point3d structs, with only some overhead for the collection as a whole, not for each individual element.
The multi-threading will also speed up certain operations, although these are always linear. Four cores equals somewhere between 3 and 4 times faster. It doesn’t lower the runtime complexity of your process. So if it took one day to process them all in GH1, it will take 3 to 4 hours to process them all on an 8-core machine. Not a huge improvement really.
It sounds like an automatic way to divvy up data into many smaller collections and deal with them iteratively sounds like something that would be useful to have, but I’ve written none of the big-projects-big-data features yet.
Probably best to get some more information first on exactly what is slow. A small sample definition would help us get a better understanding of the problem.
An expensive part of that definition is breaking a mesh into 250,000 individual single face meshes for analysis. Why not just call mesh.FaceNormals.ComputeFaceNormals()
and return the face normals from that C# script instead of creating so many tiny meshes?
No. But a plugin can add whatever types it wants. Rhino had a pointcloud type, so it wouldn’t even be that much work. The problem is that none of the existing components know how to deal with such a type, so you’d also have to create new components for all the operations you need, which is why I asked whether you were doing complicated stuff.
No nothing complicated. Just always trying to make the processing faster.
GH is a great but it looses it’s interactivity very quickly. It is what it is. And I probably have to find a way to optimise my definitions…
Will think of a way to split points data into sets of 1000 points, make an operation and then pass another 1000 …
Your mesh has more information than it needs to represent that shape. I don’t think in your case that much resolution is necessary, and even so, you could have a low poly version to iterate the development, and produce with the high quality one.
Try to do some mesh simplification to reduce the number of vertices and faces while keeping the same shape. Try MeshMachine or create it with polygon modeling or some mesh approximation.
