Volume error, same part different alignment, different volume?


I’m seeing what I think is an error in the volume command. I have a part ( same item ) orientated on two different planes.
When checking the volume I am seeing two different figures. The difference is around 1%, several orders of magnitude beyond the quoted error tolerance given in the Rhino response.

RobVolume Error.3dm (143.4 KB)

OK if I ShrinkTrimmedSrf the error reduces to around 0.001% between the two variants. This is still much larger than the quoted tolerance, at least 4 orders of magnitude.
The input surfaces used to produce the part were large, the resultant part small.
Does this imply the volume calculation tolerance is not what it might be ? If so surely the tolerance figure quoted should reflect this.


Hi Rob- thanks, I see this. Not good.


I looked at this model for a bit. The solid shown had discrepancies of calculated volume of about 2500 cubic millimeters ( a relative error of 1.7%and 10^8 times the report error bound) .

The first thing I did was ShrinkTrimmedSrf. This got the discrepancy down to about 1 cubic millimeter ( a relative error of .0001% but 10^4 times the computed error bound). Somewhere I am using the untrimmed surface where I should not be. I’ll try to track this down and fix it. But there is still a large error and an overly optimistic error bound.

The next thing I looked for is model error. This is the error in the brep model. Specifically gaps between the push_ups of the surface trims will cause errors. So if you explode the solid, run RebuildEdges on the surfaces then Join you will see there are 2 edge pairs that are not within model tolerance of .001. The worst of these was .1 I think.
Note you can also see that this error is there by running TestBrepTolerances.

So how big of a deal could this be? I rebuilt the offending surface by untrimming and retrimming with the new edges that this surface should mate to, then joining. Rerunning the test I now get a discrepancy of .01 cubic millimeters ( rel error of .000001% but still 100 times stated error bound).

So model error is not accounted for in error bound. Maybe it should be.

Finally, even after the model was cleaned up the error bound was still to optimistic by a factor of 100. I should probably try to figure out why?

I guess it all depends on how sloppy you think Rhino should be.

Greg, Pascal

Many thanks for your replies.
I noticed the error while working in grasshopper. I have a definition in development which looks at components distributed in 3D space and attempts to put a minimum volume bounding box around the parts guided by a plane found from the component geometry. The idea being to give me a cutting list of blanks ( length, width, thickness ) to carve on our CNCs. I have thousands of parts in the project I’m looking at so any savings I can find in programming time are significant
To help with programming load I also need to identify identical parts within the resulting list to reduce list length, the easiest way to do this seemed to be to classify the parts by volume ( with a tolerance value ) and one surface area ( based on project geometry type ).

I guess in this case the issue that disturbs my process is not that the volume is inaccurate so much. More that an identical part ( however faulty ) produces significantly different volume results based on orientation in space. That said the volume error is surprising, 1.7% adds up over time. Fortunately I only deal in timber, relatively low value material.

So there are three potential error sources in there, inclusion of untrimmed surfaces ( in some way ), orientation, inaccurate displayed error tolerance calculation.

As Greg says above, kind of depends on how sloppy McNeel want Rhino to be. I understand that, takes time to sort out errors like these.

That said I’m using Rhino for what I think a growing number of your users may be contemplating or doing themselves. Large scale BIM style work on complex geometries. I use the program because the alternatives available to me, AutoCAD and Inventor simply aren’t up to the task, they can’t handle the geometry.
The key I’m increasingly finding to productivity in these kind of processes is automating geometry creation and production. I suspect as that usage pattern increases ( it will, doesn’t take a rocket scientist to see what the next generation of architects are doing on Grasshopper 3D ) issues like volume being inaccurate may become more significant.


1 Like

Apologies to Greg, for Al’s reference to Rhino sloppiness.