next »

[Patheros]

I found a picking bug, or at least I think so:

At line 395 to 408 in PickingLibaray

Code:

List<PickResult> intersecting = getPickCandidates(groups, pickRay);
        //Collections.sort(intersecting);
        if (intersecting.size() > 0)
        {
            checkGeomIntersections(intersecting, pickRay, true);
            Collections.sort(intersecting);
           
            if (intersecting.size() > 0)
                return(intersecting.get(0));
            else
                return(null);
        }
        else
            return(null);

inside checkGeomIntersections (261 to 272 in PickingLibaray)

Code:

            if (intersects) {
                // write the distance into the PickResult
                Point3f p = new Point3f();
                p.scaleAdd((float)Math.sqrt(pr.getMinimumDistance()), pickRay.direction, pickRay.origin);
                pr.setPos(p);
               
                if (onlyNearest)
                    return;
            } else {
                // remove from candidates list
                it.remove();
            }

and inside PickResult at 248 to 256.

Code:

public int compareTo(PickResult pr)
    {
        if (minDistance - pr.minDistance > 0)
            return( 1 );
        else if (minDistance - pr.minDistance < 0)
            return( -1 );
        else
            return( 0 );
    }

Looking at these the pices of code the following can happen.

A and B both both canidates (in that order)
B is closer to the camera than A
A intersect and B does not

checkGeomIntersections will return after checking that A intersects leaving B in the List to be sorted to the top



I'm not sure what the inteneded way to implement this was however I think swaping the call to checkGeomIntersections and the call to Collectsions.sort would fix this problem. However I thought I'd bring this up before I (or someone else) fixed it.

[Marvin Fröhlich]

Why should B be left in the list, if it doesn't intersect? If it is, than this is a bug. But if it is removed, that everything is ok. The sort call should in any case be done after the non-intersecting candidates are eliminated. The result wuldn't be a different one, but too many candidates would be sorted otherwise.

Marvin

[Patheros]

B is left in the list because of

Code:

            if (intersecting.size() > 0)
                return(intersecting.get(0));

in checkGeomIntersections

if onlyNearest is set to true (which it is in this example) then checkGeomIntersection will return after it determines that A intersects, and never even check to see if B intersects.

[Marvin Fröhlich]

B is left in the list because of

Code:

            if (intersecting.size() > 0)
                return(intersecting.get(0));

in checkGeomIntersections

if onlyNearest is set to true (which it is in this example) then checkGeomIntersection will return after it determines that A intersects, and never even check to see if B intersects.

Ah. I see. Yes, swapping the calls should solve the problem. Do you want to do it?

Marvin

[Patheros]

Done. Enjoy.

[Marvin Fröhlich]

Done. Enjoy.

Thanks .