I am working in Kilometers and I have made a Delaunay Mesh from about 2M points, it took 3mins in the gh component. The mesh is about 500 x 100 KM but no that big in the z value. It represents a terrain, which is rather flat in some areas.
I need this mesh to be a surface not a polysurface. I thought the drape command would be ideal, but who knows why its accuracy depends on pixels?
Can someone push me in the right direction? I have run into a wall here. I need a surface to run a GH definition which only takes in surfaces, and I cannot remake it for meshes. So that is out of the question. Anything that helps me have a surface with a better resolution. It does not have to be an exact replicate from the mesh, but this Drape outcome is simply too bad. The file is quite big to upload, any theoretical advice will do.
Turn off automatic spacing, then set the U and V count in Drape to as big as you can… there is a hard coded limit, IIRC somewhere around 1000 x 500 or so…
Otherwise it should be possible to project a regular dense point grid onto the mesh and create a surface form that - point count on that can be whatever your computer can handle…
I tried the first option but there wasnt much improvement.
Regarding the second option, I already have the points… before constructing the mesh. You mean patch those points? or do you mean: Points>Daluney Mesh>Drape Point Grid>Patch Points?
Edit: Maybe I can intersect the mesh with multiple planes and generate a network surface? Gonna try that.
Nope. I mean construct PointGridSurface directly with the points (assuming they are organized in a rectangular fashion with even cell spacing, as in a typical DEM points file). There is a Surface From Points component in GH or you can use a script. If you have an ASCII Grid points file, I have an importer already written that creates a choice of pointcloud, mesh or surface from the input points.
Yes I do. This is not really relevant but my workflow involved a couple of steps to simplify the file: I actually downloaded a TIFF + ASCII file but used the TIFF to generate contours, and then imported the contour shapefile into GH with Meerkat plug in, and further simplified the Polylines. I then used discontinuity to get the points I ended up with.
OK, here it is… It assumes a standard ASCII Grid format with a rectangular projection, which files do not always follow (depending on the source). If your file is not standard format, it may error out or give you odd results. The most common one I see is that the file cell size is listed in arc seconds instead of meters because it’s a spherical projection. On the command line, you have a few options, choose surface for output type. It needs a bit of time if it’s a huge file, I have done 5000 x 5000 cells though, which is 25m points*.
*but not as a surface, that will surely crash Rhino… more than about 1000 x 1000 (1m points) is just too big for a surface
Thank you. I tried it, I think I got a different kind of projection as I got some freaky results. I inputed point density 5 and it was quite fast, about 2 mins total.
Yep, that looks like your cell size is in arc-seconds. I have an importer for that too, can post it tomorrow, but the projection will likely be off, depending on where the location is. You could take your weird looking result from the ascii import and do a Scale1D with a scale of about 1/111,111 (earth circumference degrees to meters) and see if it starts to look more reasonable.
The Patch command samples input curves to obtain points which are used in the calculations. The density of points can be set using the Sample point spacing option.
Sample point spacing
The physical distance along the input curve between sample points. The minimum is eight points per curve.
.
