When i use branchgroup.selectClosest();, how do i use the information i get to determine what object i really am picking?
branchgroup.selectClosest()?
PickResult result = mPicker.pickClosest();
if( result != null )
{
Node hit = result.getObject();
if( hit != null )
{
if( hit.getUserData() != null )
{
if( hit.getUserData() instanceof Vehicle ) // improve this
{
Vehicle v = (Vehicle)hit.getUserData();
int damage = v.getDamage();
v.setDamage( damage + 10 );
Log.logger.fine( "Cannon hit vehicle " + ((Vehicle)hit.getUserData()).getIdentity() );
PickIntersection pis = result.getIntersection(0);
Point3d imp = pis.getPointCoordinatesVW();
mImpactPoint.set( (float)imp.x, (float)imp.y, (float)imp.z );
displayHit( mImpactPoint, true );
}
}
}
Yes pickClosest i meant. 1 question though, is’nt ray involved at all in the example above?
In front I have something like that:
mShotAnalysis.setup( m3DModel.getTransformGroup() );
mShotAnalysis.mPicker.setShapeCylinderRay( mShotAnalysis.mCenter, mShotAnalysis.mAhead, 0.5 );
mShotAnalysis.mPicker.setMode( PickTool.GEOMETRY_INTERSECT_INFO );
Be careful. Picking in Java3D is based on the bounding boxes, not the actually geometry. The “closest” box is based on the center of the geometry’s bounding box, not necessarily on the closest polygon.
Is that true even when you have:
mShotAnalysis.mPicker.setMode( PickTool.GEOMETRY_INTERSECT_INFO );
defined?
Kev
Hm, I always thought it is bounds first, then geometry if needed.
And I still think it is that way.
[quote]Hm, I always thought it is bounds first, then geometry if needed.
[/quote]
It’s not that way automatically – you have to code it that way. If you use GEOMETRY_INTERSECT_INFO then picking will use the actual geometry (which is slow if you have lots of shapes!!!).
The better approach, as recommended in the javadocs, is to use Bounds picking to narrow the scope of what’s intersected, and then use Geometry intersection picking to find the exact triangle/quad/vertex that was intersected.
This is slightly more complicated to code, but definitely worth the effort.
I thought thats the way it worked already… e.g. if you request geometry intesections, it does a bounds check then a geometry check to get the exact data…
If you code it to do a bounds pick then a geometry pick you’d be doing the bounds pick twice… at least thats the way I read the java doc last time…
Kev
You can do more detailed querying against the PickResults that are returned by the PickTool.
So if you use BOUNDS to do the initial pruning, you can then get details of the intersections on the intersected node(s) using GEOMETRY_INTERSECT_INFO on the PickResults that you’ve already retrieved. Thus you won’t do any additional intersection testing on the objects that you’ve already excluded – you are just doing deeper querying on the much smaller list of objects that you’ve already done bounds checking on.