At 17:29 27/02/2003 +0100, Miguel wrote:
> > It would be valuable in that it will get more converts, but not
> > essential in that there would be no users.
>Sorry, I don't understand what you are trying to say.
I meant that there are some users who will use Jmol and similar programs
even with wireframe grfx and others who won't be interested unless they
can use it to impress others with the graphic quality. The second takes a
lot of work, but brings in more users.
> > The grfx community has several different types of user:
> > - modellers
> > - displayers
> > - printers
> > (For example many people will model a protein in O, view it in Protein
> > Modeller and publish it with Molscript or POVRAY). Don't try to
> > emulate everything!)
>Is the current povray output from jmol of "publishing quality"?
>I know that it has some limitatations
> - no double-bond support
> - none of the protein stuff: strands, ribbons, stars, curly-Qs, doo-dads :)
>How important is that stuff?
strands, ribbons, etc. are essential for proteins. I think that the Jmol
community needs to decide what approach it takes to proteins:
- must do everything that other protein programs do
- do a simple subset, including hiding some atoms
- do nothing special - all protein atoms are shown as normal Jmol atoms
Proteins are a lot of extra work and unless a Jmol developer is working on
proteins I would argue against it
>What percentage of "the chemistry community" (whatever that means)
There are many specialist areas:
- solid state
- organic molecules
These are require different functionality. I would suggest a carefully
> > There is a lot of science that is more important
>No doubt that is true. But I am only a pseudo-scientist ... a computer
>scientist. Therefore, about all I can hope to do help create some better
>tools for the scientific scientists :)
Understood. I see Jmol as a science-driven tool - a scientist uses it
because they want to understand their data. It is a bonus if it can be
nicely published. Thus it is essential to have an agreed representation of
the science because graphics can easily hide deficiencies.
> >>For example, is it important to render "charge fields" correctly for
> >> the things you are doing?
> > Yes. But we have a basic problem in that we do not have a good charge
> > field model. Is this a 3D array of vectors or an object with a convex
> > hull, etc.
>Sorry, can't help.
>I think I have seen electromagnetic fields rendered as smoothed "blankets
>of snow" (convex hulls?) with gradient colors. Are you saying that there
>is not a standard way that people think about the shapes of these fields?
I don't think there is a standard way of *representing these quantities*.
That means you may have many different types of data, each requiring its
own renderer to be written. CompChem is like that at present - special
reader for Gaussian, and probably only works for certain versions and is
> >>If *you* had some "skilled talent" to allocate for a month or two, is
> >> this the area where you would choose spend it?
> >>If not, what would *you* have me work on?
> > Wow! Actually I would concentrate on displaying molecular and atomic
> > properties at intermediate graphics resolution (e.g. charges, dipoles,
> > electron density, etc.)
>Explain in more detail please.
I mean that there are many properties of atoms that emerge from CompChem
calculations which would be nice to display. These are scalar, Vector3 and
more complex. For example the force on an atom could be represented by an arrow
> > I would also want an interactive (event) GUI.
>Do you mean that you want drive the gui with program-generated events?
That would be great. No, I meant that the GUI should trap human mouse
clicks, etc and send them to the calling program
>How does this differ from scripting?
Because in scripts the machine drives the display - in a GUI the human
drives the display
> >>It seems to me that this is the last major piece that we need to start
> >> to make Jmol an acceptable RasMol/Chime substitute. Clearly it would
> >> take a lot more polishing, but all the pieces would be there. What
> >> other pieces are missing?
> > Scripting. We have discussed this earlier.
>OK. I need some help understanding what aspect of scripting needs to be
We need a language and agree on the primitives. The language must emulate
much (?all) of what a human user does by clicking. The scripts could also
be machine-generated (?XML) so that programs could drive a display. Also
the script could log user events and replay them.
>With the exception of "protein-specific visualization stuff", jmol now
>supports *all* rasmol script commands. (no doubt there are bugs, but the
>interpreter is solid).
>Yes, the (inherited) RasMol syntax is not very modern.
>(I am about to demonstrate how little I understand about the problem space :)
>But, what is missing from the underlying functionality?
> >>Do *you* have any interest in a RasMol/Chime substitute?
> > A great deal. I would like to see Jmol provide an open source approach
> > to some/all of the CHIME functionality.
>To date, I have been working from the RasMol doc and haven't spent more
>than a couple of hours looking at Chime.
>I need some specific examples of things that Chime can do that are missing
>You don't need to send me a long list. Just send me one or two pointers
>that I can follow.
2D diagrams (cf JChemPaint). I know that CHIME does spectra. I am NOT
adding this to your list at present :-)
> > If I had such a tool I could
> > pass CML objects to it. This could include animation either from
> > implicit semantics (vibrations) or explicit - dynamics or reactions
>So, are the things you want/need animation/vibration/resonance things
>(that aren't in RasMol)?
I don't know. I suspect that RasMOL cannot animate dynamics calculations as
> >>Let me know what you think.
> > You must be brave to ask for a shopping list!
>brave? ... or stupid! :)