Nope haven’t tried it with grasshopper.
I don’t know the exact answer but according to the contour map of the site, the total height difference is roughly around 8’6" - 9’ and your answer seems to match up.
I cant say for sure if your answer is totally accurate or not because i dont know what the answer is. I was trying to compute the information using rhino.
if you want try this
min_max_pnts.gh (58.4 KB)
OK, I guess I have to do all the work here…
Bug report filed: https://mcneel.myjetbrains.com/youtrack/issue/RH-60470
@Helvetosaur The lack of accuracy of BoundingBox may require a fundamental re-write of BoundingBox to significantly revise or replace the algorithm. In general there is not a direct method for solving for the exact extrema (min/max) of general NURBS objects; iteration is needed. (There are exceptions; for example planar surfaces). One approach would be to use the existing approximate method based on the display/render mesh and determine the corresponding extrema. The refine the mesh determine the corresponding extrema, and compare the result to the previous result. If the difference is not within the desired tolerance the refine the mesh again, etc. If the difference between two levels of mesh refinement is within the tolerance then the extrema of the mesh is likely to be within tolerance of the exact extrema of the NURBS object. To increase the confidence of being within the tolerance a further refined mesh can be used and the result of that mesh tested against previous results.
Well, that is what I would have expected, but apparently it is not done. What confuses me is that in RhinoCommon we have the method GeometryBase.GetBoundingBox(Boolean) and the Boolean argument is used to select ‘accurate’ (True) or ‘fast’ (False). In the case of the test file, running a script with the ‘fast’ option is indeed worse than the ‘accurate’ (it looks like it’s operating on the underlying untrimmed surface) but the accurate option - which corresponds with the result of Rhino native BoundingBox command - is still not accurate enough (IMO).
And if I change the render mesh before running the script, it produces better results. So yes, this goes all the way down into ‘core’ Rhino.
What worries me is that I have many terrain related scripts that use bounding box for an indicator of overall elevation change. Luckily, most terrain models I deal with are meshes not surfaces, so I think I’m safe there. However looks like I will need to review and modify the scripts to force a fine mesh if the bounding box calculation runs into a surface…
The extrema of a mesh are always exactly at mesh vertices, and are relatively simple and quick to find.
Yep. Discrete points. Floating point (single or double, depending) accuracy.
Actually, iteration may not be needed. If the goal is to have the bounding box within file tolerance, all it really needs is one mesh generated that has mesh parameters of max distance to edge to surface set below that - by maybe half - plus perhaps a few others that guarantee the evenness of the sampling, like a good number of initial grid quads, a reasonable angle tolerance and max aspect ratio. If the mesh vertices could be more or less guaranteed to be within the file tolerance of the surface everywhere, one could calculate the bounding box from that.
Of course, generation such a mesh might take a bit of time, I don’t know if that is the real reason the algorithm has been implemented using the already existing render mesh. But IMO it’s just wrong to associate something that you expect to be within the set file tolerance with render mesh parameters that can be user set to anything and thus have no direct relation to the file tolerance.