I’m experiencing consistent freezes followed by crashes in Grasshopper whenever I attempt to generate what I consider relatively small meshes. The process doesn’t seem overly complex, yet it causes Grasshopper to become unresponsive and eventually crash.
Could it be a hardware issue, or might there be something about my setup or workflow that’s triggering this?
I’d really appreciate any tips or insights on how to resolve or troubleshoot this issue.
For reference, here is my Rhino system info:
Rhino 8 SR13 2024-11-12 (Rhino 8, 8.13.24317.13001, Git hash:master @ ca3666c3ebed2b9567e10930077bfa0884f65db9)
License type: Educational Lab License, build 2024-11-12
License details: Cloud Zoo
Expires on: 2025-11-01
Windows 11 (10.0.22631 SR0.0) or greater (Physical RAM: 16GB)
.NET 7.0.0
Computer platform: LAPTOP - Plugged in [100% battery remaining]
Hybrid graphics configuration.
Primary display: Intel(R) UHD Graphics (Intel) Memory: 2GB, Driver date: 10-11-2024 (M-D-Y).
> Integrated graphics device with 4 adapter port(s)
- Windows Main Display is laptop's integrated screen or built-in port
- Secondary monitor attached to adapter port #1
Primary OpenGL: NVIDIA RTX A1000 6GB Laptop GPU (NVidia) Memory: 6GB, Driver date: 6-25-2024 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 556.12
> Integrated accelerated graphics device (shares primary device ports)
- Video pass-through to primary display device
OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
GPU Tessellation is: On
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 4.6 (primary GPU's maximum)
Anti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High
Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 6-25-2024
Driver Version: 32.0.15.5612
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 6 GB
Rhino plugins that do not ship with Rhino
C:\Users\Jasper\AppData\Roaming\McNeel\Rhinoceros\7.0\Plug-ins\SpeckleRhino2 (8dd5f30b-a13d-4a24-abdc-3e05c8c87143)\SpeckleConnectorRhino.rhp "SpeckleConnectorRhino" 2.20.4.16316
Rhino plugins that ship with Rhino
C:\Program Files\Rhino 8\Plug-ins\Commands.rhp "Commands" 8.13.24317.13001
C:\Program Files\Rhino 8\Plug-ins\rdk.rhp "Renderer Development Kit"
C:\Program Files\Rhino 8\Plug-ins\RhinoRenderCycles.rhp "Rhino Render" 8.13.24317.13001
C:\Program Files\Rhino 8\Plug-ins\rdk_etoui.rhp "RDK_EtoUI" 8.13.24317.13001
C:\Program Files\Rhino 8\Plug-ins\NamedSnapshots.rhp "Snapshots"
C:\Program Files\Rhino 8\Plug-ins\MeshCommands.rhp "MeshCommands" 8.13.24317.13001
C:\Program Files\Rhino 8\Plug-ins\RhinoCycles.rhp "RhinoCycles" 8.13.24317.13001
C:\Program Files\Rhino 8\Plug-ins\Toolbars\Toolbars.rhp "Toolbars" 8.13.24317.13001
C:\Program Files\Rhino 8\Plug-ins\3dxrhino.rhp "3Dconnexion 3D Mouse"
C:\Program Files\Rhino 8\Plug-ins\Displacement.rhp "Displacement"
C:\Program Files\Rhino 8\Plug-ins\SectionTools.rhp "SectionTools"
Is there a way to reduce the number of faces in Grasshopper, perhaps while forming the loft? Since the plane is roughly 70 m², 5 million faces is really not necessary.
If that can cause problems, then that might be the issue. I use Speckle to import GIS data, and the mesh is created at various points on the map. Out of curiosity, why does that matter?
The file is quite large and contains GIS data import, so sharing it directly might not be very practical. I hope this screenshot of the generation process will suffice. Let me know if you need any additional information. Thanks in advance!
Because of how digital computers represent numbers, where computations on very large/small numbers become problematic, especially with single-precision meshes. So one might avoid very large numbers by working closer to the world origin.
Unfortunately, that’s not possible due to the GIS data input. Since the origin of the data is far away, I need to work at a distant location in Rhino to effectively use the data I require.
Is it possible to move this origin closer to where I am working?
I don’t think so. But what I’ve done in these cases is to move everything to the origin by the same vector, do all my computations there, then move everything (plus new geometry) back by the reverse vector. But again, that might become more expensive/problematic than working far from origin in the first place.
I wasn’t expecting a 3dm file (with missing blocks) and something more like the following image then the entire Grasshopper file (with 3rd party plug-ins).
Not having looked at the file, I suspect this might be the implicit casting/meshing (i.e. which occurs when passing a surface/brep to a mesh parameter). Try using the Mesh Brep component instead. Or better yet, generate the loft as a mesh in the first place, for full explicit control of the resulting mesh.
