Selection of hidden objects with shiftselect


I am using shiftselect to select several object with the rectangular area. This works fine so far but unfortunately objects that are behind other objects and can´t be seen from the view point, are selected as well.
How can I change that behaviour that only objects/shapes that can be seen are selected with the rectangular selection?


Kirill Gavrilov's picture

AIS Selection mechanism is implemented independently from graphics rendering pipeline and basically searching an intersection of a picking frustum with displayed objects:

In case of picking by a mouse cursor (AIS_InteractiveContext::MoveTo()) this frustum starts with a mouse cursor pixel from camera front clipping plane and infinitely extended within camera direction. Selection algorithm finds intersection points along this ray with displayed objects and sorts them from nearest to farthest, so that only normally only topmost object is selected.

In case of picking by a rectangle, this frustum starts with a 2D rectangle on a camera front clipping plane and infinitely extended within camera direction. Selection algorithm finds only a list of objects crossed by this frustum without any sorting, because such sorting is not applicable to this operation - it would have different solutions for different points on 2D selection rectangle.

As a result, there is no way to distinguish visible (non-overlapped) and hidden (overlapped) objects within rectangular selection. This could be emulated by performing a ray-picking per a pixel (e.g. AIS_InteractiveContext::MoveTo()) within 2D selection rectangle and filtering out objects that never appeared topmost in picking results across all picked pixels. This brute force approach is implementable using existing AIS tools but should be expectedly slow for a large number of objects.

Alternative approach would be utilizing GPU acceleration for querying overlapped objects within 2D selection rectangle. This would require a round trip between CPU -> GPU -> CPU memory, extra rendering path with a waiting for a GPU, but still should be much faster than CPU ray-tracing for a lot of pixels.

Joachim Greiner's picture

Thank you very much for your explanation and your alternative approch!