Hits framework

Development
#1

Hi,

i’ve been thinking about some changes to make to GLHit.

When manipulating crystals, it is annoying that avogadro’s picking system is
not aware of the position of an atom among its translates in a crystal.

For instance, try rotating around a given atom in a crystal.

That could be fixed by loading the position of the atom within the crystal
(the a,b,c coords) as a gl name.

So save GL selection buffer space, I suggest reusing the wasted space of
GLHit::type. I don’t think there’s a need for 32-bit-wide type, as the type
can only take 3 values (atom, bond, residue), right?
So I’d suggest to replace type with a bitfield: 8 bits for type, and the rest
(so 24 bits on a 32-bit arch) for a+aCells*(b+bCells*c).
All the corresponding computations should be done by GLHit, so I suggest by
the way improving the GLHit/GLWidget API, so that engines would just do

glwidget->loadGlName( some_atom );

or

glwidget->loadGlName( some_bond );

and it’d automatically load the type, a,b,c, parameters and the name.

Cheers,
Benoit

#2

OK, forget what I said about bitfields, it probably was a bad idea.

Other than that, I’m starting doing it now.

Benoit

On Thursday 21 June 2007 19:30:28 Benoît Jacob wrote:

Hi,

i’ve been thinking about some changes to make to GLHit.

When manipulating crystals, it is annoying that avogadro’s picking system
is not aware of the position of an atom among its translates in a crystal.

For instance, try rotating around a given atom in a crystal.

That could be fixed by loading the position of the atom within the crystal
(the a,b,c coords) as a gl name.

So save GL selection buffer space, I suggest reusing the wasted space of
GLHit::type. I don’t think there’s a need for 32-bit-wide type, as the type
can only take 3 values (atom, bond, residue), right?
So I’d suggest to replace type with a bitfield: 8 bits for type, and the
rest (so 24 bits on a 32-bit arch) for a+aCells*(b+bCells*c).
All the corresponding computations should be done by GLHit, so I suggest by
the way improving the GLHit/GLWidget API, so that engines would just do

glwidget->loadGlName( some_atom );

or

glwidget->loadGlName( some_bond );

and it’d automatically load the type, a,b,c, parameters and the name.

Cheers,
Benoit

#3

On Jun 21, 2007, at 1:30 PM, Benoît Jacob wrote:

For instance, try rotating around a given atom in a crystal.

That could be fixed by loading the position of the atom within the
crystal
(the a,b,c coords) as a gl name.

This is also a good idea if we get into stereo views inside the widget.

I’ve usually seen this by drawing everything twice (a bit like
crystals) but a slight rotation between red and green (or whatever).

In this case, the hits system also needs to know the positions aren’t
identical. So any work on a hits framework will come to multiple uses.

Cheers,
-Geoff