Help: Rhino.Geometry.Mesh.CreatePatch() questions

Hi guys, I need some help with Rhino.Geometry.Mesh.CreatePatch()

1- It seems that innerBothSideCurves needs to be closed curves, but I don’t want that, so how to I work around that in the same what that the Rhino command MeshPatch does?

Points works fine and I understand that OuterPolyLine (Boundry) and the InnerBoundryCurves (holes) needs to be closed.

  1. Why can InnerBoundryCurves be higher than degree 1 curves, but the OuterPolyline has to be a polyline (degree 1)? It would be nice if the OuterPolyline could be a higher degree curve too.

Thanks!

@dale I guess you are the one to ask about this.

To make breaklines of open curves, should I duplicate them and join them together to force them to be closed? Or is there another workaround?

@tim, is this something you can help with?

Thanks Dale.
Tim I see that if I duplicate the open polyline and join those and coerce that then I can use it as a closed curve, but not if it is a single line as that causes Rhino to think it is a null. I get this error:
“One or more of the curves is null or not closed.”

I have made a tool that makes a slab out of a boundry curve, points and inner curves:

And I would like to keep the code as clean as possible to make it easy to maintain :slight_smile:

If this is not possible I guess I have to just add an extra point to the middle of single lines.

This is a bug in the RhinoCommon wrapper. It should not require inner bothside curves to be closed.

I’ve committed a fix. You can track the progress here. https://mcneel.myjetbrains.com/youtrack/issue/RH-53052

Tim

Wicked! Thanks Tim!!
Could you consider axepting a curve for OuterBoundry as well? Now it only accepts a polyline.

Thanks!

I guess that wouldn’t really make sense, because how meshing two or more curves usually works, is that mesh faces, tris or quads, are constructed between individual, straight curve segments, which means lines.
A nurbs curve technically has no line segemts or any segments at all for that matter. However, the segments of a polyline are lines, or more correctly two points that can be connected by a line. Meshing thus works great with polylines.
Nurbs curves on the other hand first need to be divided to form polylines. This makes you lose the shape/definition of your base curve or produces huge meshes, when you go really high on the divisions. Even with many divisions, the polyline will always just be an approximation of the initial nurbs curve. Furthermore, meshes with huge polygon counts usually aren’t desired, since they are very hard to manipulate.

One other thing to consider is that you usually want to keep your meshes super tidy and clean. This entails to only use quads or tris, if possible, and keep a nice edge/face flow.

I look forward to the update since when I use the duplicate-curve-hack then that generates an edge that will extrude. So thanks for fixing that.

And another thing, could you consider adding a general direction analysis to your meshPatch output? It seems that the result is downward facing most of the time. Which doesn’t make sence sine meshPatch is mainly a 2.5D operation (Allways oriented to the XY plane):slight_smile:

MeshPatch accepts CURVES for internal use, just not boundry. It has an angleTolerance setting :slight_smile:

image

Can you upload the curves of the latest example?

Here is your previous example cleanly meshed with quads. The pink lines are the base polylines.

Hey, thanks for your interest and help mr Pirate :slight_smile:
But I know what I am after here, I even wrote my own SubD tool two years ago since I wasn’t happy with how normal SubD altered the base geometry, so my interest is purely to use the curves as they come and build a mesh according to those :slight_smile:

(I set them up based on slope analysis and height constraints, so therefore I need the mesh to do as I say, and I need nurbs curves for efficient blends and since altering polylines can sometimes be a drag (pun intended). )

1 Like

Here is a typical example of what I need to work with:


Those heights are important and therefore the boundry must be driven by curve segments so i can quickly adjust the boundry, and then I just sample those curves and convert them to polylines by a given factor. Tris or Quads are not important as I just need a quick mesh surface with a thickness for heigh analysis and overall visual evaluation.

RH-53052 is fixed in the latest Service Release Candidate

1 Like

That is fantastic, thanks for the superfast handling, I am downloading the sr candidate now and will give it a test!

Hi @dan, it works, but something else is broken now. There seems to be a memory leak in meshpatch that crashes rhino when I run an older script I have, that never failed before.
It throws an error about skipping boundry and then hangs until Rhino crashes.

I don’t know what causes it, and don’t have time to bugtrack now though. So this is just a heads up.

Not so much smarter here, but it crashes Rhino today as well.
image

This is with only internal points.

Hi @tim

I had time to look at this today and it seems that it fails when only points are used as input. (That used to work before)

Can you take a look at this code and see if you can update the patch command? Or explain why this doesn’t work any more?
Thanks!

import rhinoscriptsyntax as rs
import scriptcontext as sc
import Rhino

tol=sc.doc.ModelAngleToleranceRadians
InnerPts = rs.GetPoints()
if InnerPts:
    patch=Rhino.Geometry.Mesh.CreatePatch(None,tol,None,None,None,InnerPts,True,32)

You have to cast the first None or the compiler cannot determine which of the overloaded functions you want to call. It would look something like this in C#. Not sure how that gets scripted.

        test = Mesh.CreatePatch((PolylineCurve)null, 15 * Math.PI / 180.0, null, null, null, innerPoints, true, div);

Since you’re passing null anyway you can use either type, Curve or Polyline.

Do you have an example file, or set of steps, to exhibit the crash/memory leak you mentioned earlier?

The crash happens in a script that was compiled, but that plugin works very fine in the previous builds.
And the above patch=Rhino.Geometry.Mesh.CreatePatch(None,tol,None,None,None,InnerPts,True,32) is from that compiled script.
(I just removed all the other stuff that was going on to clean up curves and extract points etc, but that is not where the system hangs.)

AND the point is that the above script doesn’t work, but it used to.

There are 2 functions now with the same name and all of the same parameters but the first. The first parameter can be a Curve or a Polyline. If you call the function with None for the first parameter the compiler can’t tell which function you want, so it pukes. Seems brutal that it crashes but I don’t know how that stuff works, maybe that’s normal. I’ll ask Dale when he gets in if there’s a better way to do the overload. In C# it won’t even compile it you don’t cast the null so it’s not an issue there. Bear in mind, this is only a problem when null is used for the first parameter. If you pass a Curve or Polyline it will work as it has.