Rhinocommon Wishlist for Area Mass Compute Method

David et al

can you see if it possible to ask some one to implment a more basic compute method for the areamassproperties class? I only want to return the area of a brep. Its taking almost 15 seconds to calcualte the area mass properties for just 12000 breps. An option where you could have a flag to define that only certain properties are to be cauclated would hopefully really speed this emthod up,

cheers

Replies to This Discussion

Permalink Reply by Luis Fraguada on July 31, 2012 at 2:27am

This will have to be answered by someone more qualified than myself, but from what I understand, data types in Rhinocommon are purely .net. Methods might be wrappers of c++ methods, but of this I am not entirely sure.

Primitive Rhino data types in RhinoCommon are written as value classes and implemented entirely in .NET. This allows the data types to

be placed on the stack when only temporarily needed in a function

no requirement to call through to C++ to simply get the value of something like X,Y,Z in a point

no potential fragmentation of the C++ unmanaged heap because the type is entirely inside of .NET and under the control of the garbage collector

operator overloading works much cleaner since value types can not have a value of null

Permalink Reply by David Rutten on July 31, 2012 at 3:46am

Here are the details (correct me if I'm wrong about this Steve):

Rhino itself is written in C++. There is a C++ SDK that allows you to write plug-ins in C++. This is the most direct way of using the Rhino core functionality with the least amount of overhead.

Steve started developing a .NET SDK a few years back which allowed languages such as C# and VB.NET to also write plug-ins for Rhino. The first iteration of this .NET SDK was called Rhino_DotNET and it was a 1:1 translation of the C++ SDK. Basically, every class and every method was wrapped automatically with a python script. Rhino_DotNET was a mixed-mode assembly, meaning it was both C++ and .NET at the same time. Although this sounds like an ideal way to bridge the gap between a native C++ SDK and .NET development languages, Steve eventually decided it was more trouble than it was worth.

The second iteration of the .NET SDK is called RhinoCommon and it is lovingly hand-crafted by the hard-working, indigenous people of Seattle (and, to a small extend Poprad). It is very different from Rhino_DotNET. All the classes and methods have been redesigned one by one to provide a more .NET experience. A lot of C++ code has been replicated in C# to reduce overhead in critical parts. It is no longer mixed-mode.

RhinoCommon consists of two dlls, one created using C++ the other using C#. The C++ dll (rh_common.dll) exposes the core C++ SDK functionality via a large collection of easily P/Invokable functions. The C# dll (RhinoCommon.dll) defines the .NET SDK as we see it.

So, yes; using RhinoCommon (and Rhino_DotNET) will be slower than using the core SDK directly. However the overhead is roughly the same for every function call which means that functions that take a long time to compute will have negligible overhead. An overhead of 2 nanoseconds on a function that itself takes 4 nanoseconds is quite severe while an overhead of 2 nanoseconds on a function that takes 12 milliseconds is not worth considering.

Finally, Grasshopper is a pure .NET plug-in and if you wish to write plugins to Grasshopper you will have to use a .NET development language.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Arthur Mamou-Mani on September 22, 2013 at 10:14am

Thanks a lot David, very helpful reply.

Here is the C# for anyone who wants to speed he definition (half the speed):

private void RunScript(List<Brep> x, ref object A)
{
List<double> AreaSrf = new List<double>();
for(int i = 0;i < x.Count;i++)
{
AreaSrf.Add(x[i].GetArea());
}
A = AreaSrf;

}

Permalink Reply by michael sprinzl on July 31, 2012 at 6:35am

A good trick to reduce calculation time, is to mesh the object and use the mesh for calculation.

Permalink Reply by Steve Baer on July 31, 2012 at 10:00am

David,

Your description is correct.

Everyone else, David's comments about adding GetArea refer to recent additions he made to RhinoCommon which will be available in the next V5 beta (or the next Grasshopper if running in V4)

Thanks,

-Steve

Permalink Reply by Steve Lewis on July 31, 2012 at 10:51am

Can I be rude and also ask if you can extend that option so that you can also have an option to just return the area centroid too? I often use this method and if it can be speeded by not forcing a computaiton of the area mments too that woudl be great. Also same options for volumes?

Thanks all for the great feedback,

Steve