Need help for component that calculates Brep Volumes

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.

I’m simply trying to transpose @603419608 's C# script into a compiled component to make it even faster.
Volume calculation by (2.7 KB)

But of course, given my flatliner skills there’s a bunch of error messages having to do with “breps” does not exist in this context, bla, bla…

Here’s the code :

Could someone explain why this works in a script, but not in a compiled component ?

I hope this help you.

BrepVolumes.cs (1.9 KB)

1 Like

Thank you so much Naruto !

The datatype is Brep not breps, it should be something like:

List<Brep> breps = new List<Brep>();

In VS you can take advantage of the intellisense, the less you type manually, the fewer errors you will get.

1 Like

Hey @osuire,

Here is some sample code that demonstrates how to create a task-capable “just” Volume component.

JustVolumeComponent.cs (3.2 KB)

I think it works…

More on Task Capable Components

– Dale


Thanks Baris. I think I get it ; it’s just that it seems so contrived and needlessly complex compared to this :


Wait until you need to cast some datatypes :grinning:

Exactly. I hope GH 2 brings the execution speed and features I miss, and rather focus on chipping some wood than worrying about data casting or virtual function calls in abstract classes.

Hey wait a minute !


Are you working on a plugin for GH2 ?
Does that mean there’s a beta out there ???

NoJust the name.I wrote it for rhino6.

Thanks Dale.

Here’s a little benchmark :

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 added this to the wishlist yesterday


Hi Dale, I tried to create the “Just” Area variant of your .cs by naively replacing “Volume” by “Area” everywhere and disabling the part which checks for closed Breps and Meshes…

JustAreaComponent.cs (3.8 KB)

… but of course, it doesn’t work.
Could you give me a hand here ?

Hi @osuire,

Let me know if this helps:


– Dale

Hi Dale,

After much head-scratching, I figured that the strange behavior of my definition could be traced back to your component :

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.

Could you check that out please ?
Parallel computing doesnt handle empty (1.4 MB)
BlockTools.gha (56.5 KB)

Hi @osuire,

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)
  data.SetData(0, result.Volume);
  data.SetData(0, RhinoMath.UnsetValue);

– Dale

Hi Dale, my code is in fact your code :

So I suppose I should add this :

I’d start there and see if you like the results.

– Dale

It’s not finding RhinoMath…
Isn’t there a more universal way to preserve empty branches and that doesn’t look like a hack ?

Hi @dale , I can’t get over the hurdles of proper references, and such.

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.