I am looking at ways to improve our geometry validation functionality in V6. The following attachment ( VDA4955.pdf (838.0 KB) ) contains the VDA specifications for validating geometry. Section 2.3 gives a good list of potential problems that need to be detected at various times during modeling and file translation. The rest can be ignored unless you like this sort of document I am interested in hearing any input on how and when you would want to perform the tests. For example, should they be done automatically after any creation or edit, no matter how long it might take? Should there be a big Check dialog that lets you select which things to look for?
Also, some of the specs concern the relationships among a set of objects. For example, in the build released yesterday there is a command, testValidateCurveSet (a test command so you have to type it all the way out), which takes a set of curves and a bunch of tolerances. If two curves have endpoints that are less than CloseDistTol but more than GoodDistTol apart, you get a warning that there is a G0 problem. Similarly, there is CloseKinkTol and GoodKinkTol in degrees for G1 problems, CloseCurvatureTol and GoodCurvatureTol in percent for G2 problems. The idea is, say for G1, that if the angle between tangents is more than CloseKinkTol, the you want, expect, and can see, that the curves are not G1. If the angle is less than CloseKinktol, then you are expecting the curves to be G1. If the angle is less than GoodKinkTol, then the curves are really tangent and subsequent operations will work well. If the angle is between the two tolerances, then the curves look tangent but they may be off by enough to cause problems and you get a warning. Also, the command lets you know if any of the curves overlap. What interface would you like to see on tests like this?
That’s apparently a 1999 document. While it does represent a place to start, is it the latest version? It would be good to hear from Rhino users if there are any other issues not covered in this document.The question about the interface probably needs some idea of how long the checking process takes in order to answer. How representative is your example when extended to surfaces?
If the checking process is a command instead of something applied to every object at creation, presumably the user would want to select a whole bunch of stuff at once. Would the command be written to parallel process all the objects? Would objects be flagged as checked so the user could select all and the command would only check the objects not already checked?
Just some thoughts.
Its great that you are taking this to the next level.
Thanks for the feedback. It is a pretty old document, but the problems really haven’t changed much. If anything, there are a few parts of the spec that are no longer necessary. I would also like to hear what other issues should be checked. Slow processes would be done in parallel as much as is possible and actually more efficient, and it definitely makes sense to flag objects as having been checked. There are some tests that would not be necessary after some operations. For example, there is no need to check for self-intersecting surfaces after a Split or Trim, assuming the input was already checked. It may be possible for a new object to know more precisely what doesn’t need to be done.
Automatically after any creation or edit; Yes.
No matter how long it might take - well… I suppose that if it takes longer than e.g. 1 second we need a mechanism here that performs the check in a new thread or when the CPU has some idle time.
I suppose it could be settings under Rhino Options > Advanced. Only a few users would want to change the defaults I imagine - that is as long as this system only warns of validation issues and not fix them like described in the VDA document.
I’m reviving this thread because I saw on two occasions now where users post files here on Discourse and when opened in the WIP there is no immediate indication of problems. Running DupBorder on the models pops up the Check New Objects dialog box. I was wondering if the problem with the geometry couldn’t be flagged as soon as the model is opened.
The models were posted here:
and here
both @jim and @pascal point at issues that I supposed should be spotted by the validation engine.