The underwater shape of two hulls has been split into sections with each one capped to make closed breps. The Volume Centroid (‘C’ output) for the small sections at both ends of one of the hulls (not both!) is outside the brep. This kind of anomaly can consume hours of time.
The second Brep param shows the full context.
Shrinking brep faces could be a workaround; you can use shrinkTrimmedSurface component from pufferfish or a simple script like this:
brep.Faces.ShrinkFaces();
A = brep;
Volume Centroid.gh (8.4 KB)
And what does ‘brep.Faces.ShrinkFaces()’ actually do? Never mind, I don’t want to know. I don’t want to be bothered with esoteric reasons for why Rhino/Grasshopper fails. It’s a broken record that has shattered a lifelong trust in software (I’m a programmer). I want it to work the way it’s supposed to work and not routinely spend hours identifying issues like this and hours more coping with them using kludgy work-arounds. Centroid location aside, the value of the volume is important to me.
Which one is correct?
The difference between the centroid locations is measurable, though usually not so extreme as these end sections on one hull. Which values am I supposed to trust? Thank you though, I can use your centroids for this purpose and the volume values from the unshrunken breps.
volume_centroid_2020Mar21b.gh (658.7 KB)
@Joseph_Oster This may be related to the normal directions of one or more faces of the volume. For the Rhino VolumeCentroid command the normals all need to face outward. If one faces inward the result can have the calculated centroid outside of the volume. If surfaces are joined into a “solid” the normals should be automatically flipped to point outwards.
FWIW Rhino seems to follow what the GH volume component generates without shrinking trimmed surfaces.
They are all “Closed Breps” so doesn’t that mean all their face normals are outward?
To compound my frustration, I created a new, empty Rhino file to prepare the posts above, then switched back to my original GH file which was getting its geometry from Data Input, so I didn’t notice that I hadn’t reopened my original Rhino file. Much to my horror, a couple of the sliced breps now failed to Cap Holes, though I had made no changes to affect that. Took a few minutes before I re-opened my original Rhino file and all was well again.
Apparently SplitMul (Split Brep Multiple) and/or Cap Holes (not sure which) was happier with ‘Units | Absolute tolerance’ set to 0.001 (the default for a new ‘Small Objects - Feet.3dm’ file) instead of 0.01 (the default for a new ‘Large Objects - Feet.3dm’ file). 
I’ve said it before and will say it again; Rhino is the most aggravating software tool I’ve ever used. Coding has always been a refuge for me and when Grasshopper works as expected, I still get that satisfaction from it, but unpleasant surprises happen way too frequently. It’s not safe.
I don’t know if a “Closed Brep” is the same as a “Solid” in Rhino, ie a set of surfaces which are joined together with no naked or non-manifold edges, in which case I would expect the normal to all face outward.
The alternative is a “Closed Brep” just means the collection of surfaces completely encloses a volume but which may or may not be joined.
The Rhino commands Volume, Volume Centroid and VolumeMoments work with a set of surfaces which fully enclose a volume even if the surfaces are not joined into a “Solid”. If the surfaces have one or more normals pointing inward, or if one or more of the surfaces extend beyond the volume the results are incorrect.
The Rhino commands do provide a warning if the selected surfaces are not a “Solid”.
This academic gobbledygook might be quite fascinating to some but is just nonsense and lame excuses for broken code to anyone just trying to get a job done, Too many sharp edges in Rhino/GH. It can hurt you and ruin your day. Bah!
I admit though that it does clearly explain what ‘x.Faces.ShrinkFaces()’ is doing, thanks again for that. Disconcerting that volume values and centroids are so different. Still a bug as far as I’m concerned.
Are you referring to my attempt to help?
I appreciate your help, thank you again. But it’s still a bug.
What I mean by “academic gobbledygook” is that it’s all too common to hear these archaic explanations for why Rhino/GH misbehaves.
I meant to say arcane instead of archaic…
No, a ‘Closed Brep’ IS a solid, if it’s a multi-face brep (polysurface), everything must be joined and no naked edges for Rhino to report something as a closed brep. A set of unjoined faces that could make a closed brep if joined is not considered closed (i.e. not ‘solid’) if they are not joined.
