SF.net SVN: avogadro: trunk

  • src/Primitives.h: Add marker to indicate that a particular
  • src/GLEngine.h: Add glSelection enum for glPushName() entries to
    deliniate between molecule, atom, bond, residue,
    etc. picking. Render engines are responsible for using these as
    appropriate for a particular user view.

Is there any objection to putting the glPushName stuff in with the view
code instead of the molecule?

Also, because of the way residues are setup, they should actually be a
subView of the molecule which will get their own call to the engine. As
it stands there is no way to set a different renderer for each residue
which there should be.

I guess i’m just e-mailing cause it’s something i want to change but
don’t want any conflicts if there is a reason you did things the way you
did.

This brings me to another thing i just noticed. In OBMol there is a
NewAtom, NewResidue and also a CreateAtom, CreateBond yet no
CreateResidue or NewBond.

On Aug 30, 2006, at 6:26 PM, Donald Ephraim Curtis wrote:

  • src/Primitives.h: Add marker to indicate that a particular
  • src/GLEngine.h: Add glSelection enum for glPushName() entries to
    deliniate between molecule, atom, bond, residue,
    etc. picking. Render engines are responsible for using these as
    appropriate for a particular user view.

Is there any objection to putting the glPushName stuff in with the
view
code instead of the molecule?

I think you mean putting this in the view code, rather than a
particular render engine.

The reason I did this was that a “view” has no idea what a render
engine might actually show. For example, a call to render(Molecule)
might actually just be an optimized view of atoms. Or the residue
render engines, which probably need to look at a whole molecule to
construct a residue chain for a “ribbon.”

I’m honestly unsure of the need for the View classes in general. If I
want to show the same molecule in different subwindows, don’t I need
to create new GLWidget objects for each anyway?

Also, because of the way residues are setup, they should actually be a
subView of the molecule which will get their own call to the
engine. As
it stands there is no way to set a different renderer for each residue
which there should be.

I think for memory constraints, it’s better to only create a new
subView on demand for anything which is custom.

For example, let’s say I open up a 3000 atom protein. Right now, I
create 3000+ subView objects, plus 3000 Atom objects… Couldn’t I
just get away with one MoleculeView and a call to render(Molecule)
and save some cycles?

Shouldn’t we aim to make the most common things fast/easy? While I
think it’s important to allow a different residue or atom to get a
new subview and renderer, I think it’s better to create those only
when needed. Less memory, potentially less calls to set up GL, etc.

This brings me to another thing i just noticed. In OBMol there is a
NewAtom, NewResidue and also a CreateAtom, CreateBond yet no
CreateResidue or NewBond.

I’ll take a look. The naming of functions in Open Babel is hardly
systematic right now. Thanks for pointing that out.

Cheers,
-Geoff

Ok, i have a few solutions that would make me feel ok about removing
view; after loading a big molecule i see how the function calling
overhead is causing a slowdown.

I think you mean putting this in the view code, rather than a
particular render engine.

The reason I did this was that a “view” has no idea what a render
engine might actually show. For example, a call to render(Molecule)
might actually just be an optimized view of atoms. Or the residue
render engines, which probably need to look at a whole molecule to
construct a residue chain for a “ribbon.”

I’m honestly unsure of the need for the View classes in general. If I
want to show the same molecule in different subwindows, don’t I need
to create new GLWidget objects for each anyway?

primatives have a function called .pushGLName() and .popGLName() which
push the “duo” of the type and name. Done.

I think for memory constraints, it’s better to only create a new
subView on demand for anything which is custom.

I’m still not sure of this but we’ll figure something out. I can’t
image there are all that many times when you’d really want to render a
few things different. Maybe so, but i don’t know.

I fixed the code a bit so that selection now works and only picks the
closest Z. _hits is actually sorted by closest to farthest. now the
mouseRelease code actually does the selection and only for atoms. so if
you click through a bond and hit an atom it works.

I hope you find these e-mails productive and not frustrating. I just
don’t want to force anything without thinking it through. Not that you
dont’ but i’m sure, like me, you also have a lot of other things on your
plate. Avo is definatly your baby but two heads are better than one.

I want perfection in all directions.

-Donald

I hope you find these e-mails productive and not frustrating. I just
don’t want to force anything without thinking it through.

I want perfection in all directions.

I think these e-mails are great, and I’m glad to hear you say
“perfection in all directions.” :slight_smile:

Right now, I think we’re generally agreed on the render engines
themselves – make them simple to program. I think it takes me
something like 10-15 minutes to add a new engine, mostly looking up
the OpenGL calls I need. They might get some refinement, but I feel
safe adding a few.

I think MainWindow is also clear – handle the application logic. It
might have bugs, but it’s clear what belongs there. I’m glad to get
the molecule out.

On the other hand, the “middle layers” probably need more thought, so
all this discussion is really helping. As it stands, it sorta works.
As you say, it’s just a question of getting this “base” close to
perfect. Better to spend a few weeks discussing the design now than
have to rip out chunks of code later.

primitives have a function called .pushGLName() and .popGLName() which
push the “duo” of the type and name. Done.

OK, fair enough. Part of me can see the efficiency in:
glPushName(atomTypeName)
foreach(atoms) {
glPushName(atom->GetIdx();
render(atom);
glPopName();
}
glPopName();

See, there’s fewer push/pop calls. (Similarly, calls to glEnable/
glDisable can be moved outside the loop.)

i think requiring the engines to push their own name data is
unresponsible of avo because that’s important information that avo
needs
internally to function correctly.

Good point. But the View classes don’t actually know what the render
engine is going to throw up on the screen. For example, I can think
of obvious cases where it’d be good to implement a render(Molecule
*m) engine to deal with residues.

Of course thrown into this whole discussion is using multiple render
engines on one molecule (e.g., wireframe for atoms, residue ribbon
view).

I’m still not sure of this but we’ll figure something out. I can’t
image there are all that many times when you’d really want to
render a
few things different. Maybe so, but i don’t know.

Sure. Here are a few typical examples:

  • selecting metal atoms in a protein to show them as full van der
    Waals spheres.
  • selecting all water molecules and showing them as a wireframe.
  • a colleague who wants to highlight “electroactive” groups with a
    different style.

One of the main reasons I’m at all bothering with writing Avogadro is
that I just hate molecular viewers that don’t let me select atoms
or bonds and change the render style.

Two commercial products Spartan and DS Viewer can showcase some of
this. Both have free (money) demos:
http://wavefun.com/
http://www.accelrys.com/products/downloads/ds_visualizer/

e.g.
http://wavefun.com/images/odysseynosphere.jpg

Oh, there’s also a gallery from a guy who I might try to talk into
Avogadro.
http://www.pirx.com/bio_gallery/

I fixed the code a bit so that selection now works and only picks the
closest Z. _hits is actually sorted by closest to farthest. now the
mouseRelease code actually does the selection and only for atoms.
so if
you click through a bond and hit an atom it works.

Great! What needs to happen for the “rectangle selection” to work?

Cheers,
-Geoff

Good point. But the View classes don’t actually know what the render
engine is going to throw up on the screen. For example, I can think
of obvious cases where it’d be good to implement a render(Molecule
*m) engine to deal with residues.

Of course thrown into this whole discussion is using multiple render
engines on one molecule (e.g., wireframe for atoms, residue ribbon
view).

This is what worries me. Let me think about this for another day.

Great! What needs to happen for the “rectangle selection” to work?

Well, just passing the collisions to the Hit list. I’ll code it tomm if
i get a chance. It’s on my TODO list but i gotta work on this
presentation tonite.

-Donald