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.
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.
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:
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.
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)
Hey, thanks for your interest and help mr Pirate
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
(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). )
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.
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.
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.
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.