Re: [Avogadro-devel] Surfaces

[Tim V. <tim...@gm...>]

On Fri, Aug 20, 2010 at 6:06 PM, Geoffrey Hutchison
<ge...@ge...> wrote:
>> problems with the normals I think). Another options would be to use a
>> mesh simplification algorithm but I have no experience with this.
>> Ideas are welcome :-)
>
> Well, Marcus works for "the marching cubes" people, so presumably he might be able to find some people to help with mesh simplification. There's also MeshLab which is from the QuteMol people:
> http://meshlab.sourceforge.net/

I'll look into this. I have some initial succes with generating SAS
(i.e. the mesh) but the interpolated normals are not always correct.

>> Use different charges (OBChargeModel).
>> * other properties
>> Like ESP, other properties (e.g. lipophilicity, ...) could be mapped
>> to surfaces.
>
> Yes, I think we need a general mechanism to allow mapping property X to surface Y. For example, I've seen some cool work mapping the LUMO density onto the VdW surface for reactivity.

Can all properties you intend to use be expressed as a cube? I'd have
to check how the number of cube points relate to the number of
vertexes though. If there are less vertexes than cube points, it makes
sense to compute it for vertexes directly.

In any case, I think we should add a iso-surface type where the user
can specify a cube from the available cubes (This could be any kind of
cube: from file, vdw surface, ESP, ...). There will be some overlap
but there are minor differences.

Surface Types:
* Van der Waals: compute shape function cube --> create iso-surface
--> optional coloring
* Solvent Accessible: compute shape function cube --> create
iso-surface --> optional coloring
* Electrostatic Potential: Uses a cube from QM? If there is no cube
available, we can compute one --> iso-surfaces (red & blue)   [color
by should be disabled or hidden]
* Iso-Surface: create iso-surface from user specified cube
[additional combobox, hidden for other types] --> optional coloring
[only available in advanced mode?]

Color By:
* Nothing: color set in engine
* Electrostatic Potential: red - white - blue
* new color types...
* "Cube Names": since this data can be anything, user specified colors
might be nice  [advanced mode?]

We currently have a Cube::VdW type but I think we should generalize
this to Cube::Shape with the convention that the data points are the
distance from the shape's surface. Negative inside, positive outside.

It might be a good idea to store information about coloring somewhere.
The Mesh class seems an appropriate place. When available, the
information could be used by the surface engine to render a scale or
legend.

>> Are there any objections to adding OpenCL capabilities to the main
>> repository (through gerrit)? All OpenCL code would be optional of
>> course.
>
> No, I think this would be an excellent development for 1.1. I commented previously on some work in VMD that allows computing orbitals using OpenCL and they often get much better performance. I think the cube/surface code is perfect for GPU processing. Some users may not benefit, but I think we've tried to make Avogadro forward-looking where possible.

Ok, once the code is ready for review I'll push to gerrit.

> I also think there are some QtOpenCL classes in the labs.

Yes, but since it is not part of Qt yet, it would be an additional
dependency. I'm currently using the cl.hpp C++ bindings.

> -Geoff