Archived issue #0028638
Improve pick performance by applying filter before geometry checking
Description
The below function MoveTo apply filter after the pick operation. The result is no problem but it can be done in more efficient way if the filter is done inside myMainSel.
AIS_StatusOfDetection AIS_InteractiveContext::MoveTo (const Standard_Integer theXPix,
const Standard_Integer theYPix,
const Handle(V3d_View)& theView,
const Standard_Boolean theToRedrawOnUpdate)
{
...
myFilters->SetDisabledObjects (theView->View()->HiddenObjects());
myMainSel->Pick (theXPix, theYPix, theView);
// filling of myAISDetectedSeq sequence storing information about detected AIS objects
// (the objects must be AIS_Shapes)
const Standard_Integer aDetectedNb = myMainSel->NbPicked();
Standard_Integer aNewDetected = 0;
for (Standard_Integer aDetIter = 1; aDetIter <= aDetectedNb; ++aDetIter)
{
Handle(SelectMgr_EntityOwner) anOwner = myMainSel->Picked (aDetIter);
if (anOwner.IsNull()
|| !myFilters->IsOk (anOwner))
{
continue;
}
...
AIS_StatusOfDetection AIS_InteractiveContext::MoveTo (const Standard_Integer theXPix,
const Standard_Integer theYPix,
const Handle(V3d_View)& theView,
const Standard_Boolean theToRedrawOnUpdate)
{
...
myFilters->SetDisabledObjects (theView->View()->HiddenObjects());
myMainSel->Pick (theXPix, theYPix, theView);
// filling of myAISDetectedSeq sequence storing information about detected AIS objects
// (the objects must be AIS_Shapes)
const Standard_Integer aDetectedNb = myMainSel->NbPicked();
Standard_Integer aNewDetected = 0;
for (Standard_Integer aDetIter = 1; aDetIter <= aDetectedNb; ++aDetIter)
{
Handle(SelectMgr_EntityOwner) anOwner = myMainSel->Picked (aDetIter);
if (anOwner.IsNull()
|| !myFilters->IsOk (anOwner))
{
continue;
}
...
Public activity
6 archived notes
Participants are labeled by their role within this record.
> The result is no problem but it can be done in more efficient way
> if the filter is done inside myMainSel.
What do you mean "inside myMainSel", at which step???
Within BVH tree traversal?
Note that within real application selection filters might be computationally intensive.
> if the filter is done inside myMainSel.
What do you mean "inside myMainSel", at which step???
Within BVH tree traversal?
Note that within real application selection filters might be computationally intensive.
1. The first level filter can be applied to SelectMgr_SelectableObject, this level can be done before object BVH tree traversal.
2. The second level filter can be applied to SelectMgr_EntityOwner, this level can be done before geometry checking.
From my point of view, the application filter may not be computationally intensive than geomtry checking. in most real cases, the application filter should be much faster than geometry checking.
2. The second level filter can be applied to SelectMgr_EntityOwner, this level can be done before geometry checking.
From my point of view, the application filter may not be computationally intensive than geomtry checking. in most real cases, the application filter should be much faster than geometry checking.
Dear kgv,
You might be right, application filter might be implemented computationlly intensive than geometry checking, The performance will degrade in this case. Is it possible to compare the performance with OCCT internal filters such as StdSelect_EdgeFilter and StdSelect_FaceFilter?
You might be right, application filter might be implemented computationlly intensive than geometry checking, The performance will degrade in this case. Is it possible to compare the performance with OCCT internal filters such as StdSelect_EdgeFilter and StdSelect_FaceFilter?
Dear Vico,
do you have a theoretical consideration, or real use case when picking performance become a real issue for your application?
do you have a theoretical consideration, or real use case when picking performance become a real issue for your application?
Dear kgv,
I don't encounter any picking performance issue so far. When navigating the picking implementation code, the logic is not so common from my experience. Normmally, the filter is applied before geometry intersection checking, since geometry computation is computational intensive, we can exclude objects by filter quickly. anyway, it depends on the geometry intersection algorithm and strategy, in OCCT, there are two level BVH trees, the geometry checking should be much faster i think, so this should be ok to applying filter after geometry intersection checking. If applicatoin filter is implemented much faster than geometry intersection checking, applying filter before geometry checking will improve picking performance. User should be responsible for his code if he implemented a computational intensive filter.
I don't encounter any picking performance issue so far. When navigating the picking implementation code, the logic is not so common from my experience. Normmally, the filter is applied before geometry intersection checking, since geometry computation is computational intensive, we can exclude objects by filter quickly. anyway, it depends on the geometry intersection algorithm and strategy, in OCCT, there are two level BVH trees, the geometry checking should be much faster i think, so this should be ok to applying filter after geometry intersection checking. If applicatoin filter is implemented much faster than geometry intersection checking, applying filter before geometry checking will improve picking performance. User should be responsible for his code if he implemented a computational intensive filter.
Lets close the issue - could be reopened / created new one if there will be scenario where such option will boost performance.
Related records