Hi, when baking a large number of points out of an .xyz-import (2.5 million points) Rhino WIP sucks up endless amounts of RAM (until windows kills it on my 16GB workstation). Rhino 5 with Grasshopper 0.9 manages the same task with about 2.5 GB of RAM. Maybe somebody should have a look at this?
I cannot repeat that as described. If I bake the 2.5M points in the attached file, Rhino5 will use up roughly 2GB of memory, while RhinoWip uses up almost 3GB, but it doesn’t go higher. I’m running a RhinoWip debug version though, not a release build like you probably are. I hope that at least explains why RhinoWip is significantly slower than Rhino5 when it comes both to baking the points and displaying them.
2_5_M_points.gh (4.4 KB)
To anyone else wanting to test this, open the
gh file above, select the rightmost component and press the
Hi David, maybe you want to try the original file? It can be found here from now on: http://we.tl/TZpSoJ4QdU
I’ve used “Import Coordinates” on this file. Works fine until you try to bake it…
Same deal pretty much. RhinoWip slower (probably because of Debug build) and slightly more memory than Rhino5, but it works.
What happens when you save the 3dm file from Rhino5 and open it in RhinoWip?
…good point! Opening the 3dm in RhinoWip leads to the same memory-bug. So it’s not related to Grasshopper, sorry for blaming the wrong one
I don’t know how long it took to produce the cube of points - I was gone for 2 hours.
But about memory and display in RH6:
I tried to do a zoom extents but now I’m only getting the
(Not Responding)in both the Rhino and the Grasshopper title bar.
Did you import the xyz file as a point cloud or individual points? I just imported as a cloud with no problem in V6
None of the above. I used David’s grasshopper definition and pressed
Ok, I’ll assume that means 2.5 M individual points.
Yes it is. Grasshopper has no concept of PointClouds, so all coordinates are treated as individual objects.