Reconstruct Transformation Matrix
michael...@gmail.com
Imagine an input system that allows two points of contact (e.g. two
fingers). I want to ensure that as the user drags his two fingers
around, the latitude / longitude positions that he originally clicked
on remain under his fingers at all times. A couple of scenarios might
help to explain the concept.
User puts Left and Right fingers down about 300 pixels apart in the
center of the screen. User drags right finger towards the top of the
screen. That would cause a counter-clockwise rotation about the
camera's z vector as well as translating the camera towards the globe
(and I think a positive x axis post-translation, but it's hard to
envision correctly).
User puts Left and Right fingers down about 300 pixels apart in the
center of the screen. User drags both fingers away from each other
(left finger -x, right finger +x). This would result in the camera
translating towards the globe (zoom in).
The general concept is that whatever lat/long coordinates the user
clicks on remain under the respective fingers until "mouse up". This
encompasses rotation and translation. It is very easy to approximate
this behavior using an arbitrary value to rotate the proper direction,
and translate the proper direction, but I am looking for an exact
result.
I believe the Screen Space coordinates I will be getting from the input
device are only useful in calculating the World Space coordinates. So
assume that I have the World Space coordinates of:
* Original Camera position - (the World Space location of the camera at
the time of the mouse down event) - C from now on
* Left Finger (LF) start point - (the mouse down event) - LF1 from now
on
* LF current - (the current left finger position) - LF2
* Right Finger (RF) start point - RF1
* RF current - RF2
constraints:
* The Camera is always looking at the origin (0, 0, 0).
as my inputs. How would I compute where the Camera should be
positioned and oriented to ensure that the original latitude and
longitude directly map to LF2 and RF2 ?
Is this type of system best represented as quaternions or matrices (or
perhaps something else)?
Any help is much appreciated,
Michael Fawcett
Hans-Bernhard Broeker
> User puts Left and Right fingers down about 300 pixels apart in the
> center of the screen. User drags right finger towards the top of the
> screen. That would cause a counter-clockwise rotation about the
> camera's z vector as well as translating the camera towards the globe
> (and I think a positive x axis post-translation, but it's hard to
> envision correctly).
This can't really work without some additional constraint added into
the control system. The projections of two of its surface points
don't suffice to define the position of a sphere in 3D. Basically,
each "finger point" just devines a ray in world space, from the eye to
that point on the screen. The task is to fit the 3D line segment
connecting the two points on the sphere surface between those two
rays. That task is under-specified already: an edge of known length
can be fitted very freely between two diverting rays. And even after
you disambiguated this, the center of that sphere can still be
anywhere on a circle around the midpoint of that edge.
--
Hans-Bernhard Broeker (bro...@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Hans-Bernhard Broeker
> User puts Left and Right fingers down about 300 pixels apart in the
> center of the screen. User drags right finger towards the top of the
> screen. That would cause a counter-clockwise rotation about the
> camera's z vector as well as translating the camera towards the globe
> (and I think a positive x axis post-translation, but it's hard to
> envision correctly).
This can't really work without some additional constraint added into
the control system. The projections of two of its surface points
don't suffice to define the position of a sphere in 3D. Basically,
each "finger point" just defines a ray in world space, from the eye to
michael...@gmail.com
the center of the screen? That should provide three points on the
surface of the sphere:
Inputs:
Camera's z-vector (ray from center of the screen) intersection with
world.
Initial Left finger intersection with world.
Initial Right finger intersection with world.
Final Left finger intersection with world.
Final Right finger intersection with world.
Outputs:
New camera position (or, the third point of the triangle?) and
rotation.
I've noticed that the triangle that the New Camera position and the
Initial Finger positions is similar (in the mathematical sense) to the
triangle made by the Old Camera position and the Final Finger
positions.
--Michael Fawcett
Hans-Bernhard Broeker
> Can I disambiguate by saying that the camera's z-vector will always be
> the center of the screen?
Yes. This will render the interaction somewhat seriously
non-intuitive though.
michael...@gmail.com
> Yes. This will render the interaction somewhat seriously
> non-intuitive though.
I think I explained poorly if you feel this way. I will a link to a
movie demonstrating an approximation of the behavior I would like to
implement.
http://mrl.nyu.edu/~jhan/ftirtouch/
In the middle of this video clip, you'll see a user zooming and
rotating on a 2D map. This is the behavior I wish to achieve, only in
a 3D environment. The added constraint is that the camera will always
be looking at the origin (the center of the Earth, which is a unit
sphere).
The implementation shown in the video looks like a loose approximation
of mapping the user's movements to zoom and rotate commands. I would
prefer that the exact latitude and longitude that the user clicked on
remain under his fingertips.
I hope my intent is now clear.
-Michael Fawcett
Hans-Bernhard Broeker
> In the middle of this video clip, you'll see a user zooming and
> rotating on a 2D map. This is the behavior I wish to achieve, only in
> a 3D environment.
Just keep in mind that just because you wish to achieve something
doesn't guarantee it can be done, or that the result will make sense.
People have wondered about how to visually control rotation since day
one of 3D computer graphics, and the ARCBALL concept seems to have
become the almost universally accepted answer. Have you tried arcball?
michael...@gmail.com
> Just keep in mind that just because you wish to achieve something
> doesn't guarantee it can be done, or that the result will make sense.
Certainly. I hope the interaction shown in the video gives you a
clearer sense of the behavior I'm trying to accomplish.
> Have you tried arcball?
Yes. The interaction I propose is nearly identical to ARCBALL. In
single input mode (one finger on the touch table), the difference would
be that the exact point that the user clicks on remains under the mouse
(or his finger). With ARCBALL, the direction of the rotation is
preserved in an intuitive manner, but the point clicked on does not
remain under the mouse cursor. Without additonal constraints, I
realize this "single input" behavior is not well defined.
In two input mode (two fingers on the touch table), both points clicked
on would remain under the respective finger. To make this well
defined, you must add the constraint that the camera will always be
looking at the origin, and that the vector from camera position to the
origin will always pass through the center of screen space.
In single input mode, that still doesn't make the problem well defined.
You need an additional constraint. I feel the easiest is to just fake
another point of input, and solve like it was two inputs.
-Michael Fawcett
Hans-Bernhard Broeker
> Hans-Bernhard Broeker wrote:
> > Just keep in mind that just because you wish to achieve something
> > doesn't guarantee it can be done, or that the result will make sense.
> Certainly. I hope the interaction shown in the video gives you a
> clearer sense of the behavior I'm trying to accomplish.
I didn't look at it --- bandwidth's too expensive.
michael...@gmail.com
> michael...@gmail.com <michael...@gmail.com> wrote:
> > Certainly. I hope the interaction shown in the video gives you a
> > clearer sense of the behavior I'm trying to accomplish.
>
> I didn't look at it --- bandwidth's too expensive.
In the monetary sense? Are you charged proportionally to how much data
you download? I don't know anything about German ISPs, but surely
there exist better options if that is the case. The video is fairly
small (12 MB) and loads instantly for me over my connection at work. I
think you'll find the interaction with the 2D and 3D maps extremely
intuitive.
I'd love to hear your thoughts on how the problem might be solved. I
have a number of friends and co-workers trying to work it out as well,
with little to no luck so far.
Regards,
Michael Fawcett
Just d' FAQs
>I have a unit sphere (the globe) and a camera system that orbits it.
>Imagine an input system that allows two points of contact (e.g. two
>fingers). I want to ensure that as the user drags his two fingers
>around, the latitude / longitude positions that he originally clicked
>on remain under his fingers at all times.
My first suggestion is to study a classic paper,
Michael Gleicher and Andrew Witkin. Through-the-Lens Camera Control.
Computer Graphics, 26:2, pages 331-340, July 1992.
Proceedings of SIGGRAPH '92.
Gleicher's thesis may also be helpful, and perhaps a web search for
references to this paper. Here's Gleicher's web presence:
<http://www.cs.wisc.edu/~gleicher/>
Folks at Caltech did some 3D work with a "Responsive Workbench".
<http://www.gg.caltech.edu/workbench/intro.html>
And I'm too lazy to search, but you may find something helpful done at
the MIT Media lab.
Hans-Bernhard Broeker
> > I didn't look at it --- bandwidth's too expensive.
> In the monetary sense? Are you charged proportionally to how much data
> you download? I don't know anything about German ISPs, but surely
> there exist better options if that is the case.
Exist: sure. But I'm not currently using any of them.