The old (without tolerance) “Brep.CreatePlanarBreps()” syntax is deprecated. In the new form we need to provide a double that is called “tolerance”. Can you give me some guidance on how to set this value? Thanks
Providing the doucment’s model absolute tolerance is usually sufficient.
Dale, That sounds like a good answer but (being kind of compulsive) I’m wondering how that value gets set and what its affect is. Can you elaborate at all?
Also, I could use some help with the code to get this value from RhinoDoc.
More on Rhino units and tolerances.
If you working in a
You can always do this (too):
var tol = Rhino.RhinoDoc.ActiveDoc.ModelAbsoluteTolerance;
Dale, Is there any danger that a user could set this value to zero? Do you think it would be prudent to check for zero and replace with something like 0.001? Thanks, Mario
I don’t think the UI allows you to set the absolute tolerance to zero. But if you’re concerned:
var tol = DocumentTolerance(); if (tol <= 0.0) tol = 0.001; // your favorite value
var min = 0.001; // your favorite value var tol = DocumentTolerance(); return (tol < min) ? min : tol;
In case anyone is reading this and wondering …
The “ModelAbsoluteTolerence” API setting apparently corresponds to the “Absolute tolerance” value associated with a single Rhino document. (There is a separate setting for the Layout.) This is set in Rhino for a specific document from the Options menu (Tools --> Options --> Document Properties --> Units --> Model).
There is a good discussion of tolerances here:
The API setting is a multiplication factor based on the units of the model. A cursory look at the templates with my Rhino 6 has a default value of 0.01 with units feet and 0.001 with units mm. It seems to be possible to set the value to zero and I don’t know what the effect would be.
I don’t want to make too big a deal about this so I am planning to use the document value and check to prevent zero.
As a suggestion to the development team, it might be preferable to allow the old-style signature (without tolerance) and have the program use the general document setting and then offer an optional signature (with tolerance) for those developers who actually understand the effect of the value with the “Brep.CreatePlanarBreps()” command.
One of the primary goals for Rhino 6 was to consolidate the Rhino for Windows and Rhino for Mac source code into a single codebase. In order to do this, the source code had to become more multiple-document aware, as Rhino for Mac handle multiple documents. Note, Rhino 6 for Windows is still a single document application.
Thus, many SDK functions now require the developer to pass either a pointer or a reference to the active document, the active document’s runtime serial number, or some value from the active document, such as the model absolute tolerance.
Interesting. My sympathies regarding your effort to keep up with Microsoft and Apple.
I’m a little out of my depth here, but it might be useful for me to rephrase this issue for anyone who ends up reading this in the future.
The problem that a function like “Brep.CreatePlanarBreps()” has in a multi-document environment comes from the fact that the target document is not identified until the “Rhino.RhinoDoc.ActiveDoc.Objects.AddBrep()” command, which comes after the code to create the brep. This means that while historically, in a single-doc context, the function could get the document tolerance, it doesn’t know where to get it from in a multi-doc context. Therefore, the app developer needs to get if first.
This is noteworthy because it implies that there is generally no real need to override this value. Knowing this, developers can easily comply. It’s a little more problematic with people (like me) that aren’t comfortable providing a parameter value that they don’t understand.
Again, as a suggestion, it seems like this issue is going to come up in a lot of contexts. I might have preferred that you simply ask for the document pointer, instead of the tolerance, in the “.CreatePlanarBreps()” arguments list. Then app developers would know that you were using some values from the document without having to worry about what they are, and you might want to get more than one.
Alternatively, it might be preferable to allow app developers to define the document context globally for a block of code. For example, in the Revit API geometry authoring typically occurs within a transaction wrapper that is associated with a specific document.