Providing more information from VolumeMoments in VolumeMassProperties

[Andrew_Mole]

I am interested in converting solid objects produced by an architect into line objects for use in structural analysis. For this I would like to identify the principal axes of Breps. This information is clearly calculated by “VolumeMoments”, but is not made available in RhinoCommon (which I am using with Python). Would it be possible to make these principal moments and principal axes available?

This was previously requested here in the Grasshopper developer section and some solutions were offered. However, I am looking to apply this to lots of elements, so I want it to be as fast as possible. Since the information has already been calculated, it seems that it should not be too much trouble to make it available.

VolumeMoments in C#

Hi, I’m looking for a way to get the principal moments of inertia and principal axis about the centroid axes of a Brep/Mesh in C# to use in a Grasshopper component. In Rhino I can use the VolumeMoments command to get this information but I’m not able to find a corresponding API function. There is the VolumeMassProperties class which provides most of the info given by the VolumeMoments command but i can’t see the properties that I need. I the property missing? How could I get the principal axi…

[Andrew_Mole]

One more point, I notice that when the object principal axes match the global axes the “Volume Principal Moments of Inertia” are actually equal to the “Second Moments” (rather than the “Volume Moments of Inertia”). This looks like a mistake.

Interestingly, the vectors still appear to be correct, but I don’t see how it could simply be a case of reporting the wrong values for the principal volume moments of inertia, because they are the correct principal second moments, as shown in this second case where I have rotated the block by 30 degrees about the x-axis…

[GregArden]

Andrew, It looks like I messed up calculating the principal moments of inertia. Luckily it was never exposed in RhinoCommon so I guess I could fix it without messing people up. I’ll fix it in the Rhino VolumeMoments and AreaMoments commands. If you can verify the results are correct then we can add it to RhinoCommon.

The YouTrack issue:
https://mcneel.myjetbrains.com/youtrack/issue/RH-62150

[GregArden]

@Andrew_Mole Good catch. I fixed the bug in the VolumeMoments and AreaMoments commands. It should be fixed in the next Service Release candidate, probably next week.
Could you load this and verify that I’m finally calculating principal moments of inertia correctly? That would help a lot. We still need to get this calculation into RhinoCommon.

[Andrew_Mole]

Hi Greg, sorry for the slow response. I will take a look at it tomorrow.

I note that the eigenvectors appear to be correct as the principal axes (at least for the simple check I carried out). Were they based on the second moments of area or the moments of inertia?

[GregArden]

I was calculating the eigendecomposition of what I would call the moment matrix
M_{ij} = \int_V x_i x_j dV
which has the same eigenvectors as the inertia matrix
I_{ij} = \delta_{ij} \int_V ( x_1^2 + x_2^2 + x_3^2 ) dV - M_{ij}.
See the section on the Inertia Tensor in this Wikipedia article on Moment of Inertia.

The eigenvalues of the inertia matrix are principal moments of inertia.

So I believe the principal moments of inertia are correctly reported in the next service release candidate. Please let me know if you agree.

[GregArden]

@Andrew_Mole
The changes I made to the Volume Moments of Inertia in the Volume Moments report will appear in service release 3, i.e. 7.3. The first release candidate should come out today. Can you please verify I have fixed this bug.

[brian (Brian Gillespie)]

RH-62150 is fixed in the latest Rhino 7 Service Release Candidate

[Andrew_Mole]

Hi Greg, unfortunately we have not rolled out Rhino 7, so I am unable to test it. What you describe makes sense, however.

I am still in the process of trying to understand the mathematics in any case…