Hi,
When extruding curve to mesh using Rhinocommon(Rhino.Geometry.Mesh.CreateFromCurveExtrusion), it adds one unit on both top and bottom. Please see the post below.
What does this mean? How can we reproduce what you are seeing?
– Dale
Hi @dale I found this in the other topic posted above. I would be more than happy to send you a simple example but basically if you input a polyline, two points for creating a bounding box from opposing corners, and a vector for direction/amplitude (actually I have no idea why box and vector are both needed) to a c# and/or python component the result will be a mesh extrusion that goes past the start and end of the extrusion for one additional unit. I will post an example when I am able to in an hour or so.
Here you go:
Mesh_Extrusion_Bug-Example.gh (6.5 KB)
I checked and the vector’s amplitude (apparently) does nothing–the vector is only for directionality. It is instead the extent of the bounding box which controls the length of the extrusion. This whole function (while I would love it if it worked how I think it should, as a simple mesh extrusion that can take meshParams) is a head-scratcher.
I am creating thousands of these, and the script is no longer “live”. I’m trying to optimize a script that has a lot going on in it, and this was one of a few bottlenecks that I needed to fix to keep the (complex) script snappy. My goal is meshes anyways, so for these two reasons I thought it would be easier to just straight away create meshes.
Hi Dale - As Devin’s case, I am also dealing with tens of thousands of curves to turn them into meshes. I was not brave enough to convert them into Breps and then convert the BrepFaces into meshes, because, from my experiences, I knew it would take a lot of computer resources and calculation time, please correct me if I am wrong.
Hi @woojsung,
Doing pretty much anything tens of thousands of times is going to take time.
This seems reasonable fast - but what do I know. As some point, the extrusion calculation might not be the bottleneck.
test_extrude_curve_to_mesh.gh (48.1 KB)
– Dale
Yes, you’re right that this isn’t the only bottleneck (I have some intersect components in my script, which I have yet to find a more bulletproof method), but it’s a substantial, and one would think seemingly easy to fix, bottleneck.
My biggest complaint here is that it seems pretty clear to me that the result of Rhino.Geometry.Mesh.CreateFromCurveExtrusion is not working as intended, but instead of addressing that issue, you’re giving us relatively slow workarounds. This is disappointing because in my tests that function is very fast.
1 Like
Was curious, so I tested (in plain Rhino not GH). I see the extra 1mm (unit) on top and bottom. Odd. But it does seem like it’s exactly 1 unit up and down no matter what the circumstances, so you could in theory compensate for that by modifying your bounding box input.
It does seem strange though that it requires a bounding box input to determine the height - why not just use the magnitude of the extrusion direction vector?
I tried that but when I go to make the caps and seal off the open ends, it results in a very tiny gap between the flat end meshes and the extrusions
Dunno, if I use Mesh.FillHoles() it seems to cap the extrusion OK, the result is a closed mesh (in a couple of tests here). I note that everything does go completely sideways with length of the the mesh extrusion if the curve to be extruded is not perpendicular to the extrusion direction. So this method is does not appear to be a very robust one.
Lots of odd things / choices happening in mesh Rhinocommon IMO. Have you tried making your own mesh extruder? Long as you work with polyline profiles, it’s pretty straight forward.
Tiny gaps might be closed off using the FillHoles method. But would it be problematic or takes unnecessary time and CPU resource if you run any simulation that utilizes mesh face? It might be okay with one with just a few hundred, but I am dealing with ones with tens of thousands of faces. Every bit counts.
I have not tried to do that, but I would only ever be using planar closed polylines, and they would be extruded normal to their constrained plane. Could you describe to me how I would go about coding this?
Maybe you can retrieve the point array out of the given polyline, duplicate the array and move it along the z-axis, then construct quad mesh from the pair of point arrays?
FillHoles() will fill any holes detected in the mesh regardless of size - they do not even need to be planar, just have naked edges that form one or more continuous loops. Like the native Rhino command. I do not know if there is a difference in calc time between that and getting the meshes naked edges, then trying to mesh those and join the result to the original.
Yes, you’re right, using FillHoles() is probably going to fix my issues. Although the use of a bbox and vector for that mesh extrusion function are wacky to me, I am willing to jump through those hoops if it means I can use that function.
Right. That might be okay. But As I am trying to keep the consistency of input and output data, I am just trying not to create any unexpected geometries. I hate coding…