Subject: Picking reconsidered

From: [email-masked] (Lance Norskog)
Date: Mon, 2 Mar 92 09:23:16 PST

I've checked out SGI GL's picking stuff, and it's a joke.
You put the system into a special pick mode, you go through
your whole draw operation without really drawing anything,
and the system logs all the times it painted on your desired 
(x,y) coordinates.  Ick!

I've come up with four possibilities for integrated picking support.

1:
For an object-based renderer with a Z-buffer, every time you
write a Z-buffer pixel you also write the object number into
a separate array of screen dimensions.  This gives an "object map"
of the screen.  (More later)

2: Check the X&Y coordinates on each Z-buffer write when writing
a pixel.

3: For a scan-line renderer, don't do anything when painting
but just be able to call the scan-line checker with the desired
(X,Y) coordinates and have it tell you "I would have painted
this object".

4:
For a collision-based system, make a 3D line, cylinder, or rectangular 
prism extending from the viewpoint to the far wall of the world based on
a 2D point, circle, or rectangle selected with the mouse.  Check the
collision of this long thin object against the object database.

Note that #4 lets you pick not a single X,Y point, but a neighborhood.
This is much more useful.  Note that #1 also supports this, because
you can search the neighborhood of the X,Y point for objects as well.
These picking devices are not very precise, and my experience in
learning musical instruments tells me that learning to "play" a
mouse or glove or Polhemus-puck will be very very difficult.
Neighborhood picking is very important.  

#1 is a hardware-ish solution; #2 is software-ish.  We certainly
don't want the GL solution.

Lance Norskog
[email-masked]

---

From: Dave Stampe-Psy+Eng <dstamp@watserv1>
Date: Mon, 2 Mar 92 21:51:51 -0500

We're implementing something in REND386 that uses the sorted list (by order)
of polys generated by the renderer.  Just do a quick compare for each
poly to see if the point is in it-- works pretty fast.  As the Qsort to
do this takes 4 mS, you can do this anytime you need, even if you use a
scanline renderer.

- Dave Stampe

---

From: Dave Stampe-Psy+Eng <dstamp@watserv1>
Date: Wed, 4 Mar 92 01:35:23 -0500

> From [email-masked] Wed Mar  4 00:02:58 1992
> From: [email-masked] (Lance Norskog)
> To: Dave Stampe-Psy+Eng <dstamp@watserv1>, rend386@sunee
> Subject: Re:  Picking reconsidered
> 
> The case I didn't consider is glove-based picking, i.e. real 3D picks.
> For this, you need to create a transparent oddly-shaped volume
> surrounding the virtual fingers.  Or chopsticks.
> 
> Lance Norskog
> 

Or just have a sphere/box/cylinder for each finger segment...  This lets
the glove image "flex" to match the grip surface of the object.  That's
what I assume when I do my collision-detection cost calculations.
BTW, I have the time down to about 25 uS per poly/edge, but it's still
O(NN) or worse, so is still kinda infeasible so far...

- Dave Stampe