Hi,
As I am sure you have noticed between Tim and myself we have got surface
support into Avogadro. It is still pretty early stage and there are
quite a few bugs we need to iron out including some crashers. Once we
have got it working better I would like to link the step size to the
global quality level.
I would also like to add a molecular orbital engine to visualise
molecular orbitals. Then I think Tim is planning on adding an engine to
visualise docking events. I think some of our crashers originate in the
OpenBabel interpolate/getvalue functions and are easily triggered on big
molecules. I will also be adding caching so that a surface is only
calculated once and then reused unless the molecule is modified.
What else are people hoping for out of our surfaces? I will be moving
the iso.* code into libavogadro as I think it belongs with the sphere
and cylinder classes. I will be posting to my blog with a few screen
shots soon too.
I am really pleased to have this in as I feel it was one of the biggest
holes in our feature list and there are lots of things we can do now.
Thanks,
Marcus
I think some of our crashers originate in the
OpenBabel interpolate/getvalue functions and are easily triggered on
big
molecules.
That’s entirely possible. The code has not been heavily exercised
before this. (Indeed, many people didn’t know that Open Babel had
support for this.)
I will now also need to add a few more Open Babel grid formats. Right
now, we only have Gaussian. I’d like to support ADF tape files, OpenDX
(a general grid format used by APBS among others), and probably the
Jmol grid format too.
Suggestions and bugs should be forwarded to Open Babel or to me.
What else are people hoping for out of our surfaces?
Besides orbitals and general VdW surfaces? I think many people would
love to eventually map one grid (e.g., electrostatic potential or
something read in from a cube file) onto a VdW surface. In some cases,
people will read in a file which combines both molecular structure and
a mapped property (e.g., Gaussian cube), and in others, they may want
to “attach” a particular file to the surface.
In short, I see three general types of surfaces:
- Base molecular surface (e.g., like the VdW or solvent accessible
surface we have now)
- Orbitals, electrostatic potential, or other “input” surface
- Mapping of an input onto a base molecular surface
I think these can still reflect two engines. The orbital engine, for
example, needs to worry about isovalues, etc.
We also need to go code up some color gradient classes – for example,
I like to see electrostatic potential going from blue (positive
charge) to white (0.0) to red (negative charge). That’s very much a
personal taste.
Congrats to both Marcus and Tim – if you haven’t tried the surface
engine, check it out.
Cheers,
-Geoff
Hi
As I am sure you have noticed between Tim and myself we have got surface
support into Avogadro. It is still pretty early stage and there are
quite a few bugs we need to iron out including some crashers. Once we
have got it working better I would like to link the step size to the
global quality level.
I would also like to add a molecular orbital engine to visualise
molecular orbitals. Then I think Tim is planning on adding an engine to
visualise docking events. I think some of our crashers originate in the
OpenBabel interpolate/getvalue functions and are easily triggered on big
molecules.
I’ve added an additional check in OBFloatGrid::Interpolate(). This
seems to fix most crashes. It didn’t crash here yet, only time is a
problem now (slow, for large molecules).
I will also be adding caching so that a surface is only
calculated once and then reused unless the molecule is modified.
For large molecules it might also be nice to display a progress bar
while polygonizing the surface. Currently IsoGen has it’s own start()
function, but this way the thread isn’t really started, right? So, I
think, we should copy some code from the force field extension to show
a progress bar and refresh the mainwindow while the thread is running.
Tim
On Feb 10, 2008, at 3:26 PM, Tim Vandermeersch wrote:
It didn’t crash here yet, only time is a problem now (slow, for
large molecules).
I think we need some optimizations for calculating surfaces for large
molecules. One obvious one is a quick estimate on the number of
triangles and then scaling down the level of detail. If nothing
happens sooner, I should be able to talk with some people on Thursday.
There are likely other optimizations for large molecules. Programs
like Accelrys have reasonable speed for calculating VdW surfaces of
proteins. I’ve grabbed some papers, but haven’t had much time to skim.
http://www.scripps.edu/~sanner/html/msms_home.html
Cheers,
-Geoff
Hello,
Geoffrey Hutchison wrote:
What else are people hoping for out of our surfaces?
Besides orbitals and general VdW surfaces? I think many people would
love to eventually map one grid (e.g., electrostatic potential or
something read in from a cube file) onto a VdW surface. In some cases,
people will read in a file which combines both molecular structure and
a mapped property (e.g., Gaussian cube), and in others, they may want
to “attach” a particular file to the surface.
In short, I see three general types of surfaces:
- Base molecular surface (e.g., like the VdW or solvent accessible
surface we have now)
- Orbitals, electrostatic potential, or other “input” surface
- Mapping of an input onto a base molecular surface
I think these can still reflect two engines. The orbital engine, for
example, needs to worry about isovalues, etc.
We also need to go code up some color gradient classes – for example,
I like to see electrostatic potential going from blue (positive
charge) to white (0.0) to red (negative charge). That’s very much a
personal taste.
I’d just like to back up Geoff’s comments and also suggest a couple of
things that I hope will be helpful.
I’ve found the ability to map one property (e.g. the potential) on to
another (e.g. the charge density) really useful in our gui.
It’s handy too, to be able to select between a number of different
colour schemes to get the desired effect, and also have some way of
seeing the underlying structure. We do this by changing the opacity of
the surface, but I know some programs have a ‘clipping plane’ so that
it’s possible to to move a plane through the molecule and only have the
the surface rendered above or below that plane.
One thing that I’ve found important when using our stuff is to be able
to see the colour scheme that’s in operation and how it maps onto the
data. VTK has a “ScalarBarActor” that we’ve used for this.
I’ve attached a jpeg to show the kind of thing that I mean.
Congrats to both Marcus and Tim – if you haven’t tried the surface
engine, check it out.
I haven’t had a chance to look at what you’ve done yet myself, but I’m
really looking forward to trying this out soon!
Best wishes,
Jens
–
Jens Thomas, email: j.m.h.thomas@dl.ac.uk
STFC Daresbury Lab, tel: +44-1925-603849
Warrington, fax: +44-1925-603634
WA4 4AD, UK. http: http://www.cse.scitech.ac.uk
Am Sonntag, 10. Februar 2008 17:47:20 schrieb Marcus D. Hanwell:
As I am sure you have noticed between Tim and myself we have got surface
support into Avogadro. It is still pretty early stage and there are
quite a few bugs we need to iron out including some crashers. Once we
have got it working better I would like to link the step size to the
global quality level.
Do you want me to test and report bugs already? I have several smaller and
bigger issues, but I am sure you already know about them.
I don’t want to waste your time triaging bugs you already know about.
Carsten
Am Montag, 11. Februar 2008 13:46:27 schrieb Carsten Niehaus:
Am Sonntag, 10. Februar 2008 17:47:20 schrieb Marcus D. Hanwell:
Do you want me to test and report bugs already? I have several smaller and
bigger issues, but I am sure you already know about them.
I don’t want to waste your time triaging bugs you already know about.
As I was talking with Tim about this I though I can as well send the picture
to the list.
I see two bugs here:
1.) The blue area is one issue
2.) The arrow for rotation are not correctly rendered.
Carsten
Hi,
On Feb 11, 2008 1:51 PM, Carsten Niehaus cniehaus@gmx.de wrote:
Am Montag, 11. Februar 2008 13:46:27 schrieb Carsten Niehaus:
Am Sonntag, 10. Februar 2008 17:47:20 schrieb Marcus D. Hanwell:
Do you want me to test and report bugs already? I have several smaller and
bigger issues, but I am sure you already know about them.
I don’t want to waste your time triaging bugs you already know about.
As I was talking with Tim about this I though I can as well send the picture
to the list.
I see two bugs here:
1.) The blue area is one issue
Could this be fixed by adding a renderQuick() function to the engine?
Below are some general questions:
I was just reading the API documentation and Avogadro design pages
(wiki) but some concepts are not very well documented. As I understand
it, engines should only use Painters to draw stuff. The Painter
contains the OpenGL/POV-Ray specific code. Does this mean there should
be no GL code in the engines? Because most engines seem to have some
if not many gl*() calls in them. And do we always have a GLWidget? The
extensions seem to rely on it, or is this GLWidget only used in
avogadro and not libavogadro, if so where do we call
Engine::setPrimitives() from?
I also noticed there is allready a SurfaceType Primitive defined.
Should we add a new Primitive Surface class? Should this Surface be
part (child) of the Molecule.
2.) The arrow for rotation are not correctly rendered.
Carsten
Tim
On Feb 12, 2008 12:53 AM, Tim Vandermeersch tim.vandermeersch@gmail.com wrote:
Hi,
On Feb 11, 2008 1:51 PM, Carsten Niehaus cniehaus@gmx.de wrote:
Am Montag, 11. Februar 2008 13:46:27 schrieb Carsten Niehaus:
Am Sonntag, 10. Februar 2008 17:47:20 schrieb Marcus D. Hanwell:
Do you want me to test and report bugs already? I have several smaller and
bigger issues, but I am sure you already know about them.
I don’t want to waste your time triaging bugs you already know about.
As I was talking with Tim about this I though I can as well send the picture
to the list.
I see two bugs here:
1.) The blue area is one issue
Could this be fixed by adding a renderQuick() function to the engine?
Below are some general questions:
I was just reading the API documentation and Avogadro design pages
(wiki) but some concepts are not very well documented. As I understand
it, engines should only use Painters to draw stuff. The Painter
contains the OpenGL/POV-Ray specific code. Does this mean there should
be no GL code in the engines? Because most engines seem to have some
if not many gl*() calls in them. And do we always have a GLWidget? The
extensions seem to rely on it, or is this GLWidget only used in
avogadro and not libavogadro, if so where do we call
Engine::setPrimitives() from?
Just to be clear: Adding an extension to set the primitives of an
engine is possible trough the GLWidget. However, if we want this
functionality in the engine settings widget, some changes are needed I
think. Would it make sense to let an engine emit a signal when the
“Render Selected Atoms” or “Render All atoms” button is pressed? This
signal would be connected to a slot in the GLWidget, which calls
Engine::setPrimitives with the current selection or all atoms
respectivly.
I also noticed there is allready a SurfaceType Primitive defined.
Should we add a new Primitive Surface class? Should this Surface be
part (child) of the Molecule.
2.) The arrow for rotation are not correctly rendered.
Carsten
Tim