I’m trying to make a component that inputs Breps and outputs their volumes.
The problem with GH’s “Volume” component is that it also calculates centroids, and that is apparently a big contributor the execution time.
So since I don’t need the centroids, but have a LOT of volumes to calculate, well… there 'ya go opening the dreaded Visual Studio window.
Conclusion : Centroid calculation is a real resources hog !!!
All these years, I’ve been using the “Volume” component mostly for… volume, and my execution times have been crippled for no good reason.
It is obvious that Volume and centroid should be two separate components @DavidRutten .
Also, there should be some kind of tolerance input for these two functions which are used all the time.
Conclusion 2 : something in Dale’s version makes it a bit faster than Naruto’s.
I realize that it doesn’t account for empty branches, and thereafter, the data is completely shifted in the tree.
Turning off parallel computing, or feeding a tree without any empty branches solves the issue though.
I don’t have have access to the code in BlockTools.gha. But might make sure the code never returns null or nothing. In cases where the input is null or the area/volume cannot be computed, you should always return something, perhaps RhinoMath.UnsetValue.
if (null != result)
Would you mind providing a simple .cs for fast area and volume calculation that doesn’t mess up trees ?
Or, altenately, @DavidRutten , would you mind adding a “Fast area” and a “Fast volume” component in the “Surface” tab / “Analysis” section ?
I found that parsing geometry very often relies on sorting the largest or smallest area or volume, but the centroid calculation is seldom required and is just a huge ball-and-chain for execution time.