[osg-users] Is PolytopeIntersector a good choice for multiple selection?

[Neil Clayton]

Hi,

I've a scene with only a handful of Geodes (under 200).
If I wanted to detect which objects were "selected" within a 2D rectangle on screen (think clicking, holding, dragging out a rectangle over the view) - would a PolytopeIntersector be a good choice?

Code:

osgUtil::PolytopeIntersector *picker = new osgUtil::PolytopeIntersector(cf,
fmin(downX, lastX),
fmin(downY, lastY),
fmax(downX, lastX),
fmax(downY, lastY));
osgUtil::IntersectionVisitor iv(picker);
view->getCamera()->accept(iv);
if(picker->containsIntersections()) {
// do stuff
}

I ask because I've tried (using the above) - where downX/Y are filled in on mouse down - and as soon as the selection encompasses a number of geodes it really slows down, considerably (I'm doing this every time the mouse position changes, e.g: ::DRAG). I suspect I'm doing something wrong / using the polytope incorrectly perhaps?

Any pointers?
I'm considering using a nodemask to only examine the few things I need to test for (ends up being about 12 quads). But wondering if I'm doing things incorrectly from the outset...

Cheers,
Neil

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=22664#22664

_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Peter Hrenka]

Hi Neil,

Neil Clayton schrieb:

> Hi,
>
> I've a scene with only a handful of Geodes (under 200).
> If I wanted to detect which objects were "selected" within a 2D rectangle on screen (think clicking, holding, dragging out a rectangle over the view) - would a PolytopeIntersector be a good choice?
>
>
> Code:
>
> osgUtil::PolytopeIntersector *picker = new osgUtil::PolytopeIntersector(cf,
> fmin(downX, lastX),
> fmin(downY, lastY),
> fmax(downX, lastX),
> fmax(downY, lastY));
> osgUtil::IntersectionVisitor iv(picker);
> view->getCamera()->accept(iv);
> if(picker->containsIntersections()) {
> // do stuff
> }
>
>
>
>
> I ask because I've tried (using the above) - where downX/Y are filled in on mouse down - and as soon as the selection encompasses a number of geodes it really slows down, considerably (I'm doing this every time the mouse position changes, e.g: ::DRAG). I suspect I'm doing something wrong / using the polytope incorrectly perhaps?

The main problem with PoltopeIntersector is that it generates large
amounts of result data if it is used with large picking volumes.

The typical usage (as shown in osgkeyboardmouse example) is
picking small volumes where only "a handful" of picks occur.

But you are not the first one that tries to use it with larger volumes...

> Any pointers?

One possible optimization I can think of is changing the result
data structure in such a way that it only stores the intersecting
node-path and the first intersecting primitive. This data should
be enough for your usage pattern. The detailed result data could
be generated in an extra step (at a cost).

> I'm considering using a nodemask to only examine the few things I need to test for (ends up being about 12 quads). But wondering if I'm doing things incorrectly from the outset...

Using an invisible (via nodemask) "picking geometry" is certainly an
option.

> Cheers,
> Neil

Cheers,

Peter

--
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier,
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196