Closed polyline extrude to point - invalid mesh (python)

[crz_06]

I try to create an ‘extrude polyline to point’ equivalent in python to output meshes. The vanilla node gives breps and gets too slow with too many input.

It sort of works, but the mesh is invalid. Any pointers would be appreciated? I gues it has to do with

        for i in range(len(base)):
            next_i = (i + 1) % len(base)
            face = rg.MeshFace(i, next_i, apex_index)
            mesh.Faces.AddFace(face)

[mesh_extrude_to_point.gh|attachment]
mesh_extrude_to_point.gh (22.6 KB)

[dale (Dale Fugier)]

Hi @crz_06,

Is this any better?

mesh_extrude_to_point.gh (20.4 KB)

– Dale

[crz_06]

it’s a start … i do want to skip the srf/brep step and then back to mesh, as I assume it will get slow

[michaelvollrath]

Hi @crz_06,

Here’s a multi-threaded version in C#:

I adapted some Multi-Threading code from @Brian_Washburn and replaced Boolean methods with the Extrude To Point method.

Graph Space:

Model Space:

Maybe that will help you? (Sorry it’s not Python though)

20240709_Extrude_To_Point_Multi-Threaded_Response_01a.gh (25.4 KB)

[AndersDeleuran]

@crz_06

… gets too slow with too many input.

I didn’t check the file (on Rhino 7 here), but something like this doesn’t even trigger the profiler on my system:

240710_MakePyramidMesh_AHD_00.gh (19.5 KB)

[crz_06]

thank you all.
Interesting how the computation speeds are so different.
Also between old and new python nodes

attached all suggested solutions
[mesh_extrude_to_point_compare.gh|attachment]
mesh_extrude_to_point_compare_01.gh (695.1 KB)

[AndersDeleuran]

@crz_06

Interesting how the computation speeds are so different.
Also between old and new python nodes

From my testing, CPython 3 that implements RhinoCommon will be slower than IronPython, and IronPython is in turn slower than GHPython:

Rhino 8 Regression: CPython/IronPython RhinoCommon Performance Is Worse

Hi McNeel, I’ve noticed that CPython scripts will perform substantially worse when implementing RhinoCommon than IronPython (presumably because of Python.NET) . And that the new script editor with IronPython performs slightly worse than GHPython (presumably because of the new editor, since they’re both running 2.7.12 .NETCoreApp). Here’s a quick demonstration making a whole bunch of Point3d within for loops: [2024-02-05 14_54_27-Grasshopper - 230801_ScriptsMillionPoints_00_] 230801_ScriptsMi…

In some tests drastically, so if you’re going for Python + RhinoCommon + speed I’d recommend sticking with GHPython for now. And as always, following a few simple tricks can affect performance by a lot:

Grasshopper Performance - Scripting Slower Than Native Components?

Specifically for GHPython, you can usually achieve considerable speed boosts on large inputs by not using type hints or the implicit Grasshopper cycle functionality (i.e. set the access type to List if you’re operating on a list and implement the loop yourself), and on large outputs by wrapping the data in appropriate Grasshopper types: [2021-04-29 09_09_17-Grasshopper Python Script Editor] Mesh Point Remap - multiThreadTest-minimumViableFile_GHPythonFixes_00.gh (1.6 MB) See this old thread…

Also, in this case a performance bottleneck is calling Mesh.Append many times within the loop. If we do that just once, or alternatively wrap the pyramid meshes in the Grasshopper mesh type, the compute time drops quite severely:

270710_MakePyramidMeshes_AHD_01.gh (730.9 KB)

Note how the viewport is a lot more responsive if we only output one mesh for all the pyramids.

[crz_06]

@Grasshopper Performance - Scripting Slower Than Native Components?

Specifically for GHPython, you can usually achieve considerable speed boosts on large inputs by not using type hints or the implicit Grasshopper cycle functionality (i.e. set the access type to List if you’re operating on a list and implement the loop yourself

Thanks for your insightful feedback. I did notice some of the aspects you’ve mention, and figured it was just me as it didn’t make sense to me why not have a type hint would be faster (same for list/no list)

Thanks for the improve python code!

[AndersDeleuran]

Shaved a bit more off with threading, but generally speaking you’d gain more through simpler means by dropping down to C# once you start getting into 10000+ loops:

270710_MakePyramidMeshes_AHD_02.gh (745.9 KB)