Navigate tool improved

Hi,

this is to mention improvements made to the navigate tool (otherwise nobody
might notice them):

the right button dragging now behaves better: when an atom was under the
mouse, it is ensured that it will remain under the mouse by following it
exactly. When no atom is under the mouse, it is the molecule center that
follows the mouse.

the middle-button had long standing bugs from Kalzium days: they are now
fixed. Another change is that the zoom does no longer center the atom:
instead it keeps the atom fixed in the window. IMHO This feel more consistent
with the right-button action, but tell me if you preferred the centering
behavior. Manually centering is now very easy with the right button.

The rotations, with left and mid-buttons, suffered from a numerical
instability issue: after hundreds of consecutive rotations, the camera got
corrupt. This is now solved. (Also in SelectRotateTool).

General API changes:

  • in GLWidget, the unProject() and project() methods have been modified, hope
    you like it. Code has been moved from DrawTool to here.
  • in Camera, new method normalizeRotation() to contain numerical instability.

Cheers,
Benoit

On Wednesday 25 April 2007 19:17:10 Donald Ephraim Curtis wrote:

Benoit,

Is there some OpenGL builtin thing we’re bypassing by using the Camera
class?

We’re sort-of bypassing glTranslate and glRotate, yes. That’s useful because
OpenGL’s API for linear algebra is too limited for our needs:

  • only right-operations, no left-operations like pretranslate() and
    prerotate().
  • no way to compute a simple matrix-vector product (which we do need e.g. in
    distance-from-camera computations)
  • no convenient way to store the camera matrix (it’s too precious to live in
    the modelview matrix stack, where it could be modified by anyone)

Just every few months i forget what we’re doing with that class.

in addition to providing a better API for the modelview matrix, it does
construct a nice default modelview matrix for a newly loaded molecule
(initialize()) and it does handle the setting up of the perspective
(applyPerspective()).

Anyways, can we get Camera to auto-normalize?

hmm, automatically normalize after each rotation? Yes, that’s doable. I guess
that the cost of normalization is about the same as the cost of the rotation
itself. Will do that.

What’s the cost of that
function? O(n) i think.

What’s n? This function has constant complexity, like the rotation function
(keep in mind we’re always working with 3x3 matrices here, namely the 3x3
topleft corner of our 4x4 modelview matrix).

Cheers,
Benoit

Benoit,

Is there some OpenGL builtin thing we’re bypassing by using the Camera
class? I know it makes sense. Just every few months i forget what
we’re doing with that class.

Anyways, can we get Camera to auto-normalize? What’s the cost of that
function? O(n) i think. That’s not much.

-Donald

(Wed, Apr 25, 2007 at 11:27:35AM +0200) Benoît Jacob jacob@math.jussieu.fr:

Hi,

this is to mention improvements made to the navigate tool (otherwise nobody
might notice them):

the right button dragging now behaves better: when an atom was under the
mouse, it is ensured that it will remain under the mouse by following it
exactly. When no atom is under the mouse, it is the molecule center that
follows the mouse.

the middle-button had long standing bugs from Kalzium days: they are now
fixed. Another change is that the zoom does no longer center the atom:
instead it keeps the atom fixed in the window. IMHO This feel more consistent
with the right-button action, but tell me if you preferred the centering
behavior. Manually centering is now very easy with the right button.

The rotations, with left and mid-buttons, suffered from a numerical
instability issue: after hundreds of consecutive rotations, the camera got
corrupt. This is now solved. (Also in SelectRotateTool).

General API changes:

  • in GLWidget, the unProject() and project() methods have been modified, hope
    you like it. Code has been moved from DrawTool to here.
  • in Camera, new method normalizeRotation() to contain numerical instability.

Cheers,
Benoit


This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

What’s the cost of that
function? O(n) i think.

What’s n? This function has constant complexity, like the rotation function
(keep in mind we’re always working with 3x3 matrices here, namely the 3x3
topleft corner of our 4x4 modelview matrix).

Well, as far as i know, normalization is a linear operation, for matrix
i x j = n, we have to go through all n cells (are they called cells in
matrices?). Anyways, yes it’s very small for us but I would still
classify the operation as O(n). Of course in modern computing we also
have to take into consideration how many times it’s getting called.

-Donald