Maybe my trim isn’t the best way to achieve this, find my file enclosed with examples of the shapes I’m working with: close_curve_endpoints_v1.gh (447.3 KB)
My goal is to end up with a collection of closed shapes that I can extrude. These shapes can only exist on the ‘voronoi islands’.
Does anyone know a solution? I’ve already taken a considerable amount of time to find a solution, but the ones I came up with, such as finding the closest pairs of points did not yield any results. I think I’m missing one hint when it comes to the actual intersection/trim with regions component, maybe there is a better component to use for this.
What I also tried, was to convert the shape to a mesh, but this makes it considerably slower to work with as the Boundary Surface component creates a very heavy surface.
Hello Martin, thanks a lot for your suggestion. I decided to rebuild your suggestion for max learning and have to say it works well. I knew it was better to do it with some type of split but I’m not that experienced with all the intersection tools. This solution gets me exactly what I’m looking for.
You must have a better computer than I do as I get 838ms on the Surface Split component instead of your 551ms. Do you by any chance have an Intel CPU instead of my AMD CPU?
Windows 11 (10.0.22631 SR0.0) or greater (Physical RAM: 128GB)
.NET 7.0.16
Computer platform: DESKTOP
Standard graphics configuration.
Primary display and OpenGL: NVIDIA RTX A5000 (NVidia) Memory: 22GB, Driver date: 2-7-2024 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 551.52
> Accelerated graphics device with 4 adapter port(s)
- Secondary monitor attached to adapter port #0
- Windows Main Display attached to adapter port #1
Secondary graphics devices.
NVIDIA Quadro K2200 (NVidia) Memory: 4GB, Driver date: 2-7-2024 (M-D-Y).
> Accelerated graphics device with 4 adapter port(s)
- There are no monitors attached to this device!
OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 4.6 (primary GPU’s maximum)
Anti-alias mode: 8x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High
Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 2-7-2024
Driver Version: 31.0.15.5152
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 23028 MB
Rhino plugins that do not ship with Rhino
C:\Users\martinsiegrist\AppData\Roaming\McNeel\Rhinoceros\8.0\Plug-ins\KeyShot9RhinoPlugin (ecfe8d1f-876a-460f-aa5e-3dd816936811)\1.0.0.0\KeyShot9RhinoPlugin\Rhino 5.0\KeyShot9RhinoPlugin.rhp “KeyShot9RhinoPlugin” 1.0.0.0
C:\Users\martinsiegrist\AppData\Roaming\McNeel\Rhinoceros\packages\8.0\NVIDIADenoiser\0.4.3\NVIDIADenoiser.Windows.rhp “NVIDIADenoiser.Windows” 0.4.3.0
Windows 10 (10.0.19045 SR0.0) or greater (Physical RAM: 31Gb)
Computer platform: LAPTOP - Plugged in [60% battery remaining]
Non-hybrid graphics configuration.
Primary display and OpenGL: NVIDIA GeForce RTX 2060 (NVidia) Memory: 6GB, Driver date: 6-23-2023 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 536.40
> Integrated accelerated graphics device with 4 adapter port(s)
- Laptop lid is possibly closed
- Windows Main Display attached to adapter port #1
OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: 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-23-2023
Driver Version: 31.0.15.3640
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 6 GB
Do not look for brand, look for actual performance.
This kind of tasks are probably single-threaded, so look for single threaded comparison lists, like: https://www.cpubenchmark.net/singleThread.html
From my experience, cpu+motherboard performance/price ratio, AMD is better than Intel’s …
Optimize your code.
Optimize until is decently fast on old machines, then on moder machine will run real-time.
If you have solid difference going for minutes, it’s likely you have badly optimized your algorythm … or working with millions of solids? Hard to tell without seeing the actual case.
Sometime I end up replacing solid boolean operations with many pre-cut surfaces (task that can also be multithreaded) and later join them…
Absolutely right, this is why I went for AMD Ryzen in the first place back in 2020 when I realized I wanted to create artworks in Grasshopper
I have three Boolean operators running where the heaviest one runs for 5 minutes. This does a difference on one Closed BREP with 154 other Closed BREPs. I checked all of my data and there don’t seem to be any errors regarding accidentally using a Grafted tree where it needs to be flattened as well.
I’m thinking the main reason why it takes so long is because the outlines I shared in my OP original file are segmented instead of using a curve. I noticed this made it a lot heavier to process. I discovered that other thread about performing booleans through a script and am currently trying to see if that makes a difference. If it doesn’t, I will have to go and see if I can find another reasonable way of offsetting my original curves and lines with something else other than Clipper’s offset method. Beyond that the GH solid boolean operators are just notoriously slow to begin with.
I’m not in the position to share the entire file sadly as it contains an artwork I’m still working on. I’ll give the scripted boolean methods a chance and if I still feel it’s not optimized enough I’ll definitely open a new topic for it as I feel that that would be the best thing to do, also to make it so others can find a solution when looking for a similar issue and not to pollute this topic any further.
Okay, just a small addition as I couldn’t let this rest
I’ve done lots and lots of optimization to the point where I am not sure I can improve it further:
Before I found the previous topic, some booleans took over 5 minutes, so in total it was around a ten minute wait. Now it’s around one minute but it feels even shorter. I’ve done a complete rework of every group of components to make it as efficient as possible to my knowledge.
This includes, but isn’t limited to:
using the scripted boolean calls
simplifying geometry (creating an outline of segments, extruding the outlines, instead of extruding a profile along the segments)
changing how some geometry is built by using extrusions and adding a roof instead of extruding a bigger and a smaller shape and then BooleanDifference them
many more
I have a few more ideas, such as something I read about performing booleans on surfaces instead of solids.
Thanks to those that help out here on the forum. Some day I hope to show the end results in a showcase. It’s been a while, but I have to say… I love Grasshopper so much It keeps being useful in all kinds of areas.
That’s interesting as well, multiple region trims that relate to the length of the segment and the position in the list. Thanks for sharing this. I’ll have to study it some more!
Multithreading could be helpful. I’ve observed that memory size affects calculation time (16GB vs 24GB in my comparison), though it’s not a scientific setting (some other apps were open)
For splitting, my attempts has been to split one by one, and use heuristic (e.g. take smallest piece) to filter the results, so that the result of this divide-and-conquering actually adds up correctly.
Nothing to add here except a benchmark running @martinsiegrist’s code on my new computer, which looks great so far: (code is yet another victim of R8/R7 incompatibility due to Area)
HP Victus 15L Gaming Desktop Computer 12th Gen Intel 12-Core i7-12700 Processor [only 2.10 GHz]64GB RAM 2TB SSD + 1TB HDD Nvidia Geforce RTX 3060 12GB for $1,249.
It keeps being useful in all kinds of areas.