I’m creating a game using PickTool as my collision detection. I’ve come up with a large number of ways to optimize it, however my computer is really slow and I don’t know if it’s my program slowing it or just it being slow. Would you use it?
How do you relate your problem to PickTool?
-
PickTool and fastpick creates garbage. This may be a problem depending on the scene. I’ve used it for collision detection and it generated 50MB of garbage a second.
-
Java3D does a good job of culling objects using bounding volumes. But once an object is testet, it goes threw all the triangles. A custom implementation could use a BSP three to speed up collision detection.
-
you don’t get penetration depth or time of collision when using anything else than a ray. A custom implementation can do collision detection against boxes, cylinders or spheres in in a way you cant using Java3D picking.
The issue really isn’t just Java3D picking…it’s picking. Picking computes intersections, not just collision detection.
Picking is rarely used as a general case collision detection system because it is inherently much more expensive than collision detection, which is simply the overlap of geometries or bounds, and for most cases, intersection is more information than is needed to solve the problem.
Picking is really well suited to say… picking. that’s why it’s call that 
I found out what was crapping up my program… my custom subclass of Canvas3D overwrote postRender(), which slows it down considerably.
Simple Java3D programs often use a pick ray to do things like floor following and simple collision prediction.
JNWN used a pick ray for floor following in its first version and it ran just fine, no GC pauses, no slow downs.
BUu its a poor tool for “real” game collision handling. Most games use bounding volumes.