next »

[Patheros]

Please explain me, what's the difference between "the point of intersection" and "a point on the pick ray at the distance of intersection"...

There is no difference. The problem is that

Code:

The position of this PickResult's Shape3D in global-space

(PickResult line 147)

sounds like the center of the Shape3D (or the Shape3D's position) that is being picked, not the point of intersection with the Shape3D

[horati]

Given that I haven't implemented it, I don't have data structures for it yet; however, I plan to do something like the following pseudo-code if I can the intersection question answered via some API.

Assumptions:

• Mouse will always be interacting from a 2D screen so this will not work with any cool 3D headsets, etc.
• Pickray is a 1D vector in 3D space

Pseudo-code goes something like this:

Code:

   Map<BoundingBox,Object> regions = createRegions();
...
    for( Map.Entry<BoundingBox,Object> entry : regions.entrySet() )
    {
        if( entry.getKey().containsPoint( point ) )
        {
            // do something of user interest
            break;
        }
    }

Since I already know what Shape3D was chosen and each Shape3D will only have a few local regions, this O(n) search shouldn't be too bad.  If the algorithm needs to be generalized and optimized, there are obviously techniques to do so.

[horati]

I agree with Panth.  It does indeed sound like the center point which is not useful for the purpose I described above.

[horati]

Oh, I just thought of something that might be more compatible with the picking code itself.  The interface could simply be the vertices of the polygon the ray intersects.  From my side, it would be even faster to use Map<Triangle,Object> because I could just call map.get( triangle ).

Obviously, there are variants on this idea such as float[] vertices, etc.  The only important thing is that the data structure used consistently generate the same hashCode for the same vertices regardless of order OR that the vertices arrive in a deterministic order so that the hashCode will be stable.

Other than that, this is even easier, faster, and probably closer to the internals of the picking code that has to confirm ray.intersects( triangle ) anyway.

['n ddrylliog]

Lots of things to answer..

Given that I haven't implemented it, I don't have data structures for it yet; however, I plan to do something like the following pseudo-code if I can the intersection question answered via some API.

Assumptions:

• Mouse will always be interacting from a 2D screen so this will not work with any cool 3D headsets, etc.
• Pickray is a 1D vector in 3D space

Pseudo-code goes something like this:

Code:

   Map<BoundingBox,Object> regions = createRegions();
...
    for( Map.Entry<BoundingBox,Object> entry : regions.entrySet() )
    {
        if( entry.getKey().containsPoint( point ) )
        {
            // do something of user interest
            break;
        }
    }

Since I already know what Shape3D was chosen and each Shape3D will only have a few local regions, this O(n) search shouldn't be too bad.  If the algorithm needs to be generalized and optimized, there are obviously techniques to do so.

Well, what I was interested in was precisely the BoudingBox. So all regions are boxes ? How could a more complex shape be implemented ?

I agree with Panth.  It does indeed sound like the center point which is not useful for the purpose I described above.

The Javadoc is wrong. I fixed it.

Oh, I just thought of something that might be more compatible with the picking code itself.  The interface could simply be the vertices of the polygon the ray intersects.  From my side, it would be even faster to use Map<Triangle,Object> because I could just call map.get( triangle ).

Obviously, there are variants on this idea such as float[] vertices, etc.  The only important thing is that the data structure used consistently generate the same hashCode for the same vertices regardless of order OR that the vertices arrive in a deterministic order so that the hashCode will be stable.

Other than that, this is even easier, faster, and probably closer to the internals of the picking code that has to confirm ray.intersects( triangle ) anyway.

I think this is not possible with OpenGL-way picking code because it doesn't deal with triangles data structure. On the other hand, it's perfectly possible with the PickingLibrary since it goes through each triangle.. You would just have to find the nearest point to the intersection point in the intersected triangle and you have what you want.

--------------


I have just implemented the getFaceIndex() method in PickResult. Please use it only with PickingLibrary, or it will throw an Exception.

[horati]

In my initial thinking, I only considered relatively simple shapes so I figured that BoundingBox and BoundingSphere would be sufficient.

Consider for instance a gun.  If I want to know whether you touched the trigger, the exit of the barrel, the area between the hammer and the firing pin, or just somewhere else, then a series of BoundingBoxes and BoundingSpheres is fine.

Consider a control console.  If I want to know which button you pressed, BoundingBoxes are sufficient.

Consider a Football (American football with laces on the side).  If I want to know if the player gripped it by the laces, then BoundingBox is sufficient.

All the scenarios I created in my head essentially fell into these categories.  What do you think?

['n ddrylliog]

I agree, just integrates the possibility of multiple BoundingShapes for one single zone.