Bug ? Drape projects control points under the target


I’m desperately trying to find the best method to model terrains in Rhino and am currently testing several workflows.
I extracted a topographic mesh of a random location using Heron as a base for benchmark.

Now I’m trying to transform this mesh into a surface.

I found the Drape command but I have a problem with the output surface that floats under the mesh. Not just the surface, but most of its control points.
If I understand the description of the command correctly, it should build a grid of points, project those on the target objects along CplaneZ, and use those points as the control points of the surface ?
But the points themselves are under the target…
Doing the projection using Project works fine, so this doesn’t seem to be a tolerance problem.

DrapeBug.3dm (2.4 MB)

Hi @magicteddy, as far as i know _Drape has always been slightly inaccurate depending of the size of the viewport and the accuracy of the depth buffer. The help doc mentions this:

Drape samples locations in the render depth buffer (z buffer) and then uses them for the surface control point locations. Because of this, the surface will always sag more than the original

Maybe you could try to use _DupBorder and then _Patch the polyline with the mesh selected. This would make things a bit more flexible as you’re not bound to rectangles. Alternatively, select all surface control points and project them to the mesh.


Hi -

You are not saying what the ultimate goal is, or the reason why you need this to be a surface. Why not just keep it as a mesh?
Incidentally, MeshRepair flags the mesh in your file as a bad mesh with a degenerate face and non-manifold edges.
I suppose you could run QuadRemesh on this with SubD output and convert that to NURBS…

I don’t know either, I’m trying to grasp the advantages/drawbacks of using meshes vs surfaces vs SubD, depending on what I have as input data. I’m having a hard time finding appropriate ressources to explain that and it’s the first time I’m facing topography in Rhino.

So far my conclusion is that a mesh should be used to model the whole terrain from points and/or contour curves, using MeshPatch, because it’s ligher, then if I need to sculpt this terrain locally (adding a road or whatever feature that requires the terrain to be leveled) and building a smooth transition to it, BlendSrf was the first thing that got into my mind, hence the need for a smooth surface patch. I don’t see myself adding mesh faces by hand but maybe this would be also a valid workflow.

I tried QuadRemesh but even with a lot of quads I have deviations to the existing topographic points. I could go to SubD with the original Delaunay mesh using points as locations, but the result is not very clean as SubD doesn’t really like triangular faces.

The Drape problem I mention here is merely a small part of the investigation I’m running right now, but since it was awkward I thought I’d post it here. I’ll try again with a simpler mesh to see if the same problem shows up. By the way I checked with the What command and Rhino says the mesh is valid here, I didn’t think to go further with MeshRepair.

Same problem with a simple Delaunay mesh which MeshRepair flags as good.
I guess as @clement says there is a larger tolerance because it’s using Z buffer, but isn’t the render mesh supposed to be exactly the same as the mesh itself in this case ?

Anyway I think I’ll just remove Drape from my list of concerns for now.
I can build a grid in Grasshopper, project it and use SurfaceFromPoints

ValidMeshYetDrapeProblem.3dm (1.5 MB)

Hi @wim, i’ve too first thought that this is the reason for the deviation and repaired the mesh. But it gives the same output in V5, V6 and V7 even when the file tolerance is lowered and the AutoDetectMaxDepth is set to No and MaxDepth is set to 1.0. My guess is that the ZBuffer range is not fine enough.


Hi @magicteddy ,
I am curious how you are getting the topo mesh you posted. If you are using the Import Topo component from Heron to generate a mesh topography from a raster file, you should be getting a clean quad mesh with well ordered vertexes. With this mesh, you can then select a subset of the vertexes to create a Surface From Points.

If you are looking at projecting a surface to the mesh as @clement describes, Heron’s Multi Move To Topo component can help.


1 Like


I used Heron to get a clean topo mesh with a grid, baked, then ran Contour and then MeshPatch.
I’m doing this because I have a client that will most likely use elevated 2D contour curves/points to recreate topography, thus will be unable to start from online data.

As a larger problem, I’m trying to find a decent method to be able to edit that kind of terrains locally - adding roads or changing the shape, and having a smooth transition to the terrain that is unchanged. Most tutorials I saw used surfaces and/or boolean oprations hence the need to recreate a local surface… And consequently the problem with Drape (that, on a side note, was the original point of this topic and is still a problem of its own, regardless of the insanity of the method I’m trying to apply here :sweat_smile:)

Thanks for your time and great job with Heron !

1 Like