Hatch Selection Error


#1

I seem to have uncovered a bug where the extents of a hatch are not properly detected. I came across the bug when calling the ObjectTable.FindByWindowRegion method in a Python script; I’m passing the viewport bounds and would expect objects wholly visible in the viewport to be found (I’m primarily testing in the parallel viewport). The behavior is just as expected for Curves and Breps: so long as the object is wholly visible in the viewport, it is found. Hatches (even those that are identical in extents to Breps and Curves), are not always found as anticipated.

What I’ve discovered is that in order for the hatch to be found, its entire WORLD-ORIENTED BOUNDING BOX (and not just it geometry) has to be included in the FindByWindowRegion bounds.

World Oriented Bounding-Box INSIDE Viewport:


_
World Oriented Bounding-Box OUTSIDE Viewport:

I’ve tested with a dramatically simplified version of the script (to make sure there were’t script errors) and have also discovered that this impacts the command ZoomSelected when used in the native Rhino enviroment (i.e. no scripting). In SetZoomExtentsBorder, I’ve set ParallelView=1, so I would expect that ZoomSelected would zoom tightly to an object in a parallel viewport. Again, Curves and Breps behave as expected. For a hatch, ZoomSelected zooms to the extents of the WORLD-ORIENTED BOUNDING BOX.

ZoomSelected on Curve or Brep:


_
ZoomSelected on Hatch:

Hopefully my description is clear enough to illustrate the bug. Please let me know if I can assist further.

-Jason
Version 5 SR14 64-bit
(5.14.522.8390, 5/22/2017)


(Dale Fugier) #2

HI @moosejuicezeus,

Can you provide a sample script, and a sample model if needed, along with any instructions need for us to reproduce what you seeing?

Thanks,

– Dale


#3

Sure thing. Sample model and simplified Python script attached:
Hatch Error.3dm (433.3 KB)
Hatch Error.py (408 Bytes)

I’m going to focus my description on recreating the error in the native Rhino environment, but the Python error seems congruent. (I’m assuming the the ObjectTable.FindByWindowRegion method and Rhino’s ZoomExtents/ZoomSelected ultimately rely on the same code somewhere in RhinoCommon).

The sample model contains two viewports: the default Top view (WorldXY Cplane), and Top_ROTATED whose Cplane is rotated 15-degrees (still coplanar with World XY). A random closed polyline curve is drawn on layer “Curve Outline”. The Hatch command is used to create two hatches: one created with Top as the active viewport/Cplane, one created with Top_ROTATED as the active viewport/Cplane, each on its own layer. The BoundingBox command is used to create a Bbox around the hatch in the same viewport/Cplane as the hatch was created (these curves are locked and are only for illustrative purposes; the error exists without them).

For illustrative purposes, use SetZoomExtentsBorder for ParallelViews=1. (The error persists with the default setting of 1.1, but this makes it more clear: ZoomSelected/ZoomExtents should zoom tightly to objects).

Select the curve on “Curve Outline” and run '_Zoom _All _Selected. This is the expected behavior: both viewports zoom tightly to the curve:

Select the WorldXY hatch and run '_Zoom _All _Selected. Only the Top viewport zooms as expected:

Select the Top_ROTATED hatch and run '_Zoom _All _Selected. Only the Top_ROTATED viewport zooms as expected:

The same error occurs in the attached Python script. The script is quite simple: get the active viewport, pass it and its bounds to Objects.FindByWindowRegion, print all the returned objects. The curve on “Curve Outline” is always found as long as it is wholly in the active viewport. The hatch is found ONLY if the Bbox corresponding to the Cplane it was created in is wholly in the active viewport.

Hope this helps.


(Dale Fugier) #6

Hi @moosejuicezeus,

Thanks for the details. It appears to be a bug in the hatch object’s tight bounding box calculation. I’ve reported this as a bug, and it should be fixed in an upcoming Rhino WIP.

https://mcneel.myjetbrains.com/youtrack/issue/RH-40345

– Dale


(Brian Gillespie) #7

RH-40345 is fixed in the latest WIP