Unfortunately, the polhemus sensors are magnetic, and they have difficulty performing at the far ends of the table. This causes the virtual cue to be spaced far apart from the stylus which makes shots difficult. We could get around this by smoothly rotating the rectangular pool table. Now either the pool table will have to shrink to completely fit on the workbench or it will be clipped or it will have to be of a smaller shape that can rotate without clipping or scaling.
Since we plan on affixing a real pool cue to the stylus, scaling of the pool table is bad because the real world pool cue no longer matches the dimensions of objects in the virtual world. Clipping the pool table is really bad because we cannot see the objects or holes that are our final destinations. Creating a smaller pool table that can rotate without scaling or clipping is also undesirable because it reduces the playable area quite a bit. This either requires us to reduce the dimensions of all the objects or use large dimensions with a small number of objects. If we reduce the dimensions, the real pool cue will not match the virtual world sizes, but the tip of the cue and the size of the poolball will be much smaller and the balls will become hard to hit. With smaller distances, sensor error becomes much more prominant. We need a large pool ball and large cue tip for a useful game. If we use a small size pool table with large feature sizes, we will have to reduce the number of pool balls and perhaps the number of holes. The game is not as much fun with only 3 balls on the playing field.
Our solution was to keep the large pool table size, and only allow rotations by 180 degrees. Only the tip of the virtual cue collides with balls, so in areas of poor sensor performance, the user can move back to a good area and "hook" the poolball with the inside edge of the virtual cue tip. There is no right answer in this case, and it is often a matter of personal preference. If we have time, we plan on allowing the user to pick one of several different pool tables so they can have their choice of which method to use.
We've identified 2 possible scenarios. The first, which we implemented as the default, has the outside edges of the pool table at z==0 and the felt below the table surface. The virtual cue is long enough to "reach through" the glass to the pool balls below. Since the edge of the table is at z==0, our real estate is maximized, and it provides a stable image. Users can form a bridge with their fingers, but jamming the real pool cue into the table can still be a problem. The other scenario is to put the felt at z==0 and the balls and edges are now above the surface of the table. The 3D stereo effect is best above the table, but this consumes more real estate. Again, this choice is a matter of person preference, there is no "right" answer. We plan on making the pool table height a user selectable option.
There are 2 spotlights over the pool table, so the virtual cue casts 2 shadows. As the cue tip is moved closer to the surface of the table, the 2 shadows point at each other and begin to intersect. If we had more time, we would turn on a scraping noise when the cue intersects with the table. When the tip of the cue hits a poolball, a sound is generated and the ball begins to move. The combination of sound, shadows, and motion is very effective.