AIS_InteractiveObject: Why does picking use presentation bounding box instead of sensitive entity for initial filtering?

[akakazeruri]

In OpenCASCADE's interactive object design, the presentation object and sensitive object of AIS_InteractiveObject are separated and can be different. However, when picking objects, OCCT uses the bounding box generated by the presentation object for collision detection filtering. Isn't this a logical bug? Shouldn't it be designed to use the sensitive object's bounding box for collision detection during picking?

[akakazeruri]

The bounding box of AIS_InteractiveObject always only takes PrsMgr_PresentableObject::BoundingBox(). When my sensitive object and presentation object are not in the same location (or even when I don't have a presentation object at all), the picking result deviates from my expectation.

[gkv311]

As you've been found out, the first-level BVH tree relies on AIS_InteractiveObject::BoundingBox(), which basic implementation returns bounding box of displayed PrsMgr_Presentation. The logic behind this choice is simple - the selection should be done only for something that is actually seen on the screen.

Presentation bounding box is expected to be always computed beforehand (it is also used for frustum culling in a renderer and for camera's automatic Z-fit), while computation of lower-level BVH trees could be deferred until object's bounding box is hit; different selection modes could be enabled/disabled for the object without invalidating BVH tree of the first level - maintaining performance and simplifying logic.

However, when dealing with advanced visualization matters (like custom shaders), one of the common issues is to forget updating bounding box of presentation (Graphic3d_Group::SetMinMaxValues() when adding groups in ::Compute(), or not calling Graphic3d_Structure::CalculateBoundBox() after manual modifications outside of ::Compute()), so that one may still see the object, but unable to pick in the viewer, despite correct sensitivities provided by ::ComputeSelection(). Although this might look confusing, it is important providing correct bounding box for presentation anyway, taking into account local transformation and other things.

I may see only one scenario, when one may intentionally want to define selection outside of main presentation - for dynamically highlighting some auxiliary entities like snapping points, center of radius, etc., but it still possible to handle them by providing own implementation of AIS_InteractiveObject::BoundingBox() within subclass or expanding presentation's bounding box with extra points.

I tend to agree, that current implementation is somewhat error-prone to above-mentioned issues, presentation mismatches selection (usually by mistake in the other place, but anyhow - debugging such issues is counter-intuitive), still it is possible to solve these issues using current API. Changing this logic at AIS side and separate bounding boxes for presentation and for selection might solve some issues, but will require a careful investigation to avoid performance degradation in normal / special scenarios.

The first level tree is constructed of axis-aligned bounding boxes of each selectable object. Hence, the root of
this tree contains the combination of all selectable boundaries even if they have no currently activated selections.
Objects are added during the display of AIS_InteractiveObject and will be removed from this tree only when the
object is destroyed. The 1st level BVH tree is build on demand simultaneously with the first run of the selection
algorithm.
The second level BVH tree consists of all sensitive entities of one selectable object. The 2nd level trees are built
automatically when the default mode is activated and rebuilt whenever a new selection mode is calculated for the
first time.
The third level BVH tree is used for complex sensitive entities that contain many elements: for example, triangula-
tions, wires with many segments, point sets, etc. It is built on demand for sensitive entities with more than 800K
sub-elements (defined by StdSelect_BRepSelectionTool::PreBuildBVH()).

[akakazeruri]

Thanks a lot for the reply! This definitely confirms the right way for me to deal with custom interactive objects. I'm pleasantly surprised to receive such a detailed response from the team—thank you all for your amazing work!