Hmmm… (Tested in V7 and WIP)
NoVolume.3dm (2.0 MB)
1 Like
I’ve asked the developer to take a look.
I’ve poked around a fair amount and can’t find any reason Volume would fail, yet it does.
Yeah, I poked a bit too here before posting. Thanks JB!
How was this Rhino polysurface made? If we knew how it was made we could fix the construction code.
Another tack for this common problem is what to do with the “problem object” once it exists in the world. Here are some options:
-
Check - The Check command could detect the problem and identify the issue.
" Polysurface 1610f45f-94c3-4d1f-a65f-47521181a0fa , Face[24] is invalid.
Loop 0 is self intersecting or overlapping. Trim[0] intersects Trim[1] in the interior." -
Check could additionally suggest a fix for the user to implement themselves.
" Try to fix the polysurface using ExtractBadSrf, DupBorder, UntrimAll, Trim and Join." -
There could be a repair command in Rhino that the user invokes, maybe it takes the error location info that was spit out of Check i.e. "1610f45f-94c3-4d1f-a65f-47521181a0fa , Face[24] ". The user decides if the fixed geometry should replace the bad geometry.
-
The Volume command could run the repair function behind the scenes and report the volume of the fixed geometry. The source geometry remain flawed and could cause more problem downstream. The user gets no notification that all this happened but they get a number and hopefully it’s right.
-
In addition to 4. the source geometry could be modified so when the model is saved the change is permanent. This would then hopefully fix the geometry for any future use.
What would be the right approach for geometry error detection and repair?
1 Like
Here is the face that I repaired by hand using the suggestion I posted above.
RH68212.Face24Fixed.3dm (75.3 KB)
i tried check on the failing geometry on mac and it did not complain about anything did i misunderstand the command? or is that actually what you are suggesting the command should do (in future)?
I am suggesting that check should detect the error. If Check reported the error message would that be enough for you to fix the problem on your own?
it would at least be a starting point rather than having nothing. but i might be still lost then not sure.
Check in V7 does not currently complain about the closed polysurface.
That seems to be the underlying problem here.
I assume that’s some future implementation of Check - I checked the object several times… always “valid”. SelBadObjects does not select it either.
One of the classics for creating problems I guess - OffsetSrf… I will go back and retrieve the original surface collection from which this was made and post it here with instructions.
Of the options above, some kind of automatic repair routine the operator could run once the bad trim has been identified would be my choice. I wouldn’t just fix the object behind the scenes to make the Volume command magically work. In cases where Volume fails, I usually mesh the object and run Volume on the mesh which gives me at least a good approximation.
Edit: here is the example - instructions in the file.
NoVolumeExample.3dm (2.4 MB)
Yeah, I assumed it probably had to be around there somewhere - the square-to-round line-to-arc lofts are the only ‘complicated’ surfaces in the original…
One implication of adding this criteria to Check, is that it makes many models invalid These problems exist in many models where no one is complaining. Detecting them might not really be a service to users.
I would rather know there is an imperfection, and perhaps decorate it that it may not be critical, much like Check does when evaluating a mesh with a few minor problems.
Without that indication of even a minor problem, I’m left in this state and nothing to try. I have a “Valid polysurface” according to Check, yet Volume fails and does not report why.
Maddening.
3 Likes
i agree with John, i dont see much sense being kept from the truth … also, how did you find the problem actually? something we normal earthlings can do to replicate that?
Yes, that is a difficult choice. Many users will not want to see this if nothing downstream will be affected.
This brings me back to long discussions we had on the old newsgroup as early on as V2 about wanting to have an advanced user panel where one could choose what kind of model ‘problems’ should be flagged by Check/CheckNewObjects. There were even requests to flag things that normally pass without a problem - for example when internal multiknot surfaces are generated (such as extruding a line joined tangent to an arc).
Internally, we have called this category of possible tools “Check for Humans”.
It’s an ethereal, mythical beast as far as I can tell, and will never quite become a real tool.
I think back in those days, we called them “Vaporware”.
1 Like
Thanks I opened a bug on OffsetSrf. RH-68217 OffsetSrf makes bad geometry
The problem is generally contained in one or more faces. It shows up with Area as well as Volume. So you can Explode and test buckets of faces until it is isolated to failing faces. At this point I would try the DupBorder, UntrimAll, Trim and see you can get a face that works with Area. Then replace the failing face with the fixed face and your good to go.
Here’s a script that I use to extract faces that fail in Area.
ExtractAreaFailures.py (1.8 KB)
To use the Python script use RunPythonScript, or a macro:
_-RunPythonScript "Full path to py file inside double-quotes"
-Pascal
i would claim when somebody runs check they want to find out in more detail whats going on and will certainly be prepared for all issues. limiting a command which is meant to show exactly that makes imho really no sense. also in this case the surface really is not valid if one can call it that. offsetting this face once more creates a tiny folding
just in case somebody not knowing already wants to have a look i pointed out the zaggy corner.
NoVolume.3dm (3.7 MB)
maybe using a different language avoiding valid invalid and replace it with a short note of the issues.?
i would even avoid that
is that some kind of rain gutter actually?