multi-touch-dev team mailing list archive

[Duncan McGreggor <duncan.mcgreggor@xxxxxxxxxxxxx>]

Hey Thomas,

I can only take credit for the menial data entry job of that wiki page
:-) Henrik Rydberg's brain is responsible for the explorations you read
there. Henrik is a very active member of the kernel, X, and open source
HCI community, not to mention a core contributor to the
gestures+multitouch-on-linux effort.

That being said, I really appreciate the time you took to put this all
into writing and communicate it to me (us). We are great appreciators of
the long-standing work done by the PyMT developers and are glad to be
working with more and more of you :-)

I'm forwarding this to the multi-touch dev mail list, of which not only
Henrik is a member, but many other great minds in the HCI community.

Thanks again,

d

-------- Original Message --------
Subject: Gesture Motion Model
Date: Wed, 6 Oct 2010 17:00:01 -0500
From: Thomas Hansen <thomas.hansen@xxxxxxxxx>
To: Duncan McGreggor <duncan.mcgreggor@xxxxxxxxxxxxx>

I saw your write up on https://wiki.ubuntu.com/Multitouch/Dev/Gestures

I've worked and reworked the scale/rotate/translate widget (MTScatter)
in pymt a couple of times (mostly for API reasons, but also figuring
out the best way to compute the transformation form the touch events
).  I saw your wiki entry
(https://wiki.ubuntu.com/Multitouch/Dev/Gestures), and thought I'd
share a couple of thoughts.  I think my approach is a bit simpler, but
I'm not sure it is as comprehensive as what you describe.  Either way
I'm very interested in figuring out what the best way to approach this
problem is for various use cases.

I'll ignore the scaling part, its pretty straight forward to separate
it out or to add on top of just rotate/translate if you make sure to
scale using the pivot as the origin.

I'm not sure I understand the formulas, you written down completely, so
sorry if I got something wrong.  It sounds like you want to think of
the transformation as a combination of rotate + translate.  In my
experience it's much simpler to think of it as just a series of
rotations around different pivots (and really the idea of translation
only makes sense with respect to some fixed origin).  If I understand
correctly, your describing a model for representing the gesture, I'm
talking about specific implementation here but it still related i
think.

The whole thing actually gets pretty easy to compute, as long as you
limit yourself to using two contact points and you assume that you
process events sequentially (only one contact move at a time, but this
can be done manually even if events are reported without this
constraint).  I'm attaching 2 illustrations I've made for
presentations/documentation.

Limiting everything to two contact sounds a lot worse than it is at
first. If you only allow rotate/translate (+/-scale), you're defining a
conformal affine transformation, which is well defined for 2 points.
If you have >2 points and they do not stay in exact relation to each
other, the transformation is not well defined.  When you have your
fingers on a piece of paper e.g., notice how your fingers will stick
to the same spot on the paper...this doesn't not happen easily on a
touchscreen, because the surface you touch does not actually move,
which means you either stick to two points or approximate the
transformation/try to do a best fit.

I think the trick is to pick the "correct" two contact points to use
for the calculation.  A very simple approach is to just use the first
two contacts, or two arbitrary ones, and then stick with them as long
as their live.  Based on playing with different strategies, I think
the most intuitive thing is to pick two points that lie on the minimum
bounding circle enclosing all points under consideration (although
this is non trivial to compute..but pretty fast for small number of
points like touch contacts).  By using just two contact points, you
can grantee that those fingers stay on the same spot in your
transformed space (e.g. virtual piece of paper), this is not the case
if you calculate/approximate based on more than 2 contacts, and the
results end up behaving very unnaturally/not intuitively (or i've been
doing it wrong, but i've tried a lot of different things over the last
two years).

If you apply those constraints, calculating the transformation becomes
trivial.  All you have to do is compute the angle between the lines
(a,b), and (a, b'), where a is the stationary contact, and b/b'  is the
original and new position of the second contact.  Then rotate by that
angle using a as the pivot.

If you want to report or think of it as translation + rotation, you
can extract this information from the accumulated transformation.  For
example in pymt, I apply the rotation around the stationary contact to
a 4x4 matrix (for use in openGL), and its easy to split it into a
translation + rotation matrix (translation vector + rotation about
some origin). so e.g. I can access the center, and angle properties of
the widget that implements this interaction technique to get a
translation/rotation around center.


Anyways, just thought I'd share my thoughts, since reading the wiki
page made me think about this :)

--
Thomas

Attachment: rts.png
Description: PNG image

Attachment: rts2.png
Description: PNG image