Hi,

I just found that `Rhino.IsObjectInBox`

does not take any tolerance into account.

Would it be possible/wise to add that?

Thanks

-Willem

Hi,

I just found that `Rhino.IsObjectInBox`

does not take any tolerance into account.

Would it be possible/wise to add that?

Thanks

-Willem

It would certainly be possible to write a function of your own that would work the same as IsObjectInBox but include a “grace region” with a tolerance so that if the object you were checking inclusion for was just outside of the box but close it could still return true. However, since ObjectInBox is not making a value judgement such as “do these curves come ‘close’ to one another” (where close could mean different things in different situations), it doesn’t make sense to consider a threshold tolerance. The object is either In (true) or out (false); there is no middle ground, since both the object and box you are checking have a precision defined by the Rhino doc’s units. It will always be an absolute check.

e.g. on a number line if your “object” is 1.0001 and your box is [-1.000,1.000], but your theoretical document precision is 0.000, your object will actually be evaluated/recorded as 1.000 and IsObjectInBox will return true. Conversely, if your document precision is 0.0000, it will return false.

Hi Bert,

I see your points, however my thinking is that since the method accepts geometry as argument

Rhino.IsObjectInBox (**strObject**, arrBox, [blnMode]), an optional tolerance would be in place.

Mathematically I fully agree with you, however for practical use, working with Rhino created geometry and not allowing for any tolerance is more error prone that having a certain amount of tolerance.

My specific case is a part of surface split by a sphere, Rhino.IsObjectInBox did not catch the trimmed surface as being inside the spheres boundingbox. The deviation however is far below the file’s absolute tolerance.

I have indeed worked around now by adding my own tolerance.

-Willem

Actually, you raise an interesting point. My assumption would be that the test you’re performing should return true since all points of your trimmed surface(s) fall within or on the boundary of the sphere. In this case I would say the Rhino method is somewhat buggy, or at least lacks an adequate explanation of how it performs the test. In the absence of bugs, It must be the case then that IsObject is designed to test on an open interval, and so returns false whenever the object is not *completely* within bounds (i.e. it has points *on* the boundary). I myself would have implemented a closed interval test so that an object would test true as long as all its points were within or on the boundary. I believe NURBS can represent spheres/circles in a mathematically perfect way, so the method shouldn’t be failing due to the trimmed face “faceting” outside the sphere or something of that sort.

Would you mind posting the code you wrote? I’d be interested to know how you implemented the test yourself.

Hi Bert,

In my opinion there is nothing buggy here:

Splitting in Rhino is performed within file tolerance. So a deviation between the 2 bounding boxes is expected, to difference can be +/- the file tolerance.

The way I made is work, is to expand the bounding box of the sphere like so:

```
Function BBoxExpand(BBox, dblExpand)
Dim BBoxMM :BBoxMM = array(BBox(0), BBox(6))
BBoxMM(0)(0) = BBoxMM(0)(0) - dblExpand
BBoxMM(1)(0) = BBoxMM(1)(0) + dblExpand
BBoxMM(0)(1) = BBoxMM(0)(1) - dblExpand
BBoxMM(1)(1) = BBoxMM(1)(1) + dblExpand
BBoxMM(0)(2) = BBoxMM(0)(2) - dblExpand
BBoxMM(1)(2) = BBoxMM(1)(2) + dblExpand
Dim x1,y1,z1,x2,y2,z2
x1 = BBoxMM(0)(0)
y1 = BBoxMM(0)(1)
z1 = BBoxMM(0)(2)
x2 = BBoxMM(1)(0)
y2 = BBoxMM(1)(1)
z2 = BBoxMM(1)(2)
BBoxExpand = array(array(x1, y1, z1), array(x2, y1, z1), array(x2, y2, z1), array(x1, y2, z1), array(x1, y1, z2), array(x2, y1, z2), array(x2, y2, z2), array(x1, y2, z2))
End Function
```

-Willem