> 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!) OK.
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) wants/needs it?
There are many specialist areas: - solid state - organic molecules - polymers - proteins
These are require different functionality. I would suggest a carefully chosen subset
> 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 platform dependent
>>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 extended.
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 from Jmol.
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 Jmol does
HTH>>Let me know what you think. > > You must be brave to ask for a shopping list! brave? ... or stupid! :)
P
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
