About the Jmol project
How do you write Jmol?
Is there another JMol?
How do I reference Jmol in published papers?
Using Jmol
How can I learn to use Jmol?
Can Jmol be displayed in my language?
Hardware requirements
What are the minimum hardware requirements?
What are the recommended hardware requirements?
Is OpenGL or 3D hardware required to run the JmolApplet?
Application system requirements
What platforms does the Jmol application run on?
Performance
Performance is great! Why is it so fast?
Rendering speed is really slow. What can I do?
Will a 3D graphics card improve performance?
Why does it get so much slower when I make the window bigger?
Graphics and rendering
How are the graphics different in Jmol v10?
I see jaggies. Why aren't the graphics anti-aliased?
But I need some higher-quality images ...
Does Jmol support isosurfaces?
What shapes does Jmol support for protein secondary structure?
JmolApplet deployment
For the applet, what must be installed on web client machines?
Jmol.js JavaScript Library
Can the JmolApplet be permanently installed locally, like a plug-in?
What MIME types must be installed on the server?
Should I use APPLET, OBJECT or EMBED for my html tag?
I am having problems with loadInline
The loadInline param does not seem to work
Scripting questions
rotate Z ; rotate Y ; rotate Z
Capital J, lower case mol
Please do not write it any other way ... to avoid confusion with
other projects ... keep reading ...
Yes, there is a project called JMol ... but not Jmol ... note the
difference in spelling.
Will York wrote the JMol viewer at the
Complex Carbohydrate Research Center,
University of Georgia, USA. The home page was at
http://www.ccrc.uga.edu/~will/jmol/jmol.html
(it is no longer there).
Both on the web and in published papers you should
reference Jmol in this way:
Jmol: an open-source Java viewer for chemical structures in 3D. http://www.jmol.org/
See the
home page for some hints.
Yes, likely!
Jmol is a fully internationalised program (meaning that it can
adapt its interface to be displayed in one of several languages)
and it has been localised (meaning that there
are several translations available and built into the program).
Check
the Wiki
for the list of currently supported languages.
If your language is in the list, Jmol should automatically open
using it. If it doesn't, either the language you want is not your operating system
language (which is the one Jmol will choose), or something is failing
(but this is uncommon).
You can force Jmol into using any of the available languages in several ways:
- Upon start: visit this Wiki page
for instructions.
- Dynamically after Jmol has started:
using the 'Language' entry near the bottom of the pop-up menu.
Please, don't change language many times, as Jmol may lock.
You can also do it from the console, using the 'language' command;
see link above for details.
If your language is not in the list, you may volunteer to collaborate
as translator. Please, read instructions in
this Wiki page
and, if you need help, contact the developers team.
400 MHz CPU + 128 MB RAM
There is no absolute minimum. This is a practical minimum.
Performance is a function of
molecule size, window size, and image complexity.
750 MHz CPU + 256 MB RAM -- Of course, more is better.
No special hardware is required to run the JmolApplet.
The graphics engine is a z-buffer implemented in Java,
and designed for rendering molecules. (In fact, designed
just for Jmol.)
The Jmol application should run on any system that supports
Java 1.4. Previous versions of Java are not supported.
It does not use any Java graphics calls. The entire
image is built offscreen and sent to the screen with one
java.awt.Graphics.drawImage operation.
- Get a faster machine ... something built this century
- Convince Sun to fix graphics performance problems
- Review the source code and find some way to speed it up
A high-performance graphics card will certainly help.
The underlying system spends a lot of time blitting 32-bit
RGB bitmaps to the screen. But no 3D capabilities of the card
will be used.
Twice as many pixels means twice as much work ... and if your
applet is twice as wide and twice as high then you have 4 times
as many pixels so you get 1/4 the speed.
A new 3D graphics engine has been developed for Jmol v10 to
properly support intersecting shapes. This is important
when viewing spacefilled molecular models.
The 3D engine also has much higher performance when dealing
with larger molecules.
No java graphics calls are used in the construction of the image.
The entire scene is constructed in memory and transferred to the
screen with one drawImage operation.
Hey ... aren't you the person who was complaining about speed?
Recent (v11) versions of Jmol allow to use antialiasing,
both for the display and for exported images. Check out
Jmol
Scripting Documentation.
Export from the application to POV-Ray, or
increase the size of the application window, or
learn how to open Jmol in even larger sizes and export images
without display, using the command line.
Yes. Starting with version 10.2, Jmol has some functionality
for rendering isosurfaces,
that is greatly expanded on version 11.0.
Using RasMol/Chime terminology, Jmol current supports
backbone, trace, strands, ribbons,
meshribbons, cartoons, and rockets.
No special Jmol-specific software needs to be installed
on the client machines.
Client machines do not need anything other than a web browser
that supports Java, and a recent version of Java installed and enabled
in the browser (best is Java Virtual Machine from Sun).
When a client visits a web page containing the JmolApplet, the
applet gets automatically downloaded from the web server and
executed.
The JmolApplet runs as an untrusted applet. The applet
does not any confirmation from the user to load and begin
execution. There is also a trusted version of the applet
(JmolAppletSigned)
for authors that prefer to make use of its advantages
(see TechNotes, Browser Enhancement Technologies
for details).
It is strongly recommended that you
use the Jmol.js JavaScript Library
to allocate your applets within your web pages.
No.
Applets get cached in the local browser cache. Subsequent uses of
the applet will pull the applet from the cache
(after confirming that the date/time/size have not changed
on the web server). At least, that's the theory ...
and it works correctly on the browsers I have seen :-)
None. The web server needs no special configuration.
Applets do not get associated with MIME types in the same way that
plugins do. While the Chime plugin requires configuration
of the web server, the JmolApplet does not.
Check out the Tech Note on
Browser Enhancement Technologies
You are strongly recommended to use the
Jmol.js JavaScript Library,
since it will automatically insert the best choice according to the
user's browser.
If you insist on doing it yourself,
EMBED is not good for applets; APPLET is
better than OBJECT.
Do not be confused by the Sun Java Plug-in developer documentation!
Unfortunately, the Sun Java Plug-in documentation does not do a good
job of explaining the current state of the world. The doc was written
several years ago and really needs to be cleaned up. In many places
it still seems to recommend the use of the OBJECT tag.
That is the way things used to be up until about 2002.
Since then the Sun Java
Plug-in has had direct support for the APPLET
tag on Microsoft
Internet Explorer, and this issue has essentially gone away.
However, Sun needs to maintain the doc for legacy corporate intranet
applications that were deployed using the OBJECT tag.
Chapter 12 of the Sun Java Plug-in developer guide says:
With Internet Explorer it is recommended that you use the
APPLET tag for internet deployment.
...
With Netscape it is recommended that you use the
APPLET tag for internet deployment.
You should probably use the
Jmol.js JavaScript Library
Make sure you make a clear distinction between the
loadInline param tag and the loadLine method.
You should probably use the
Jmol.js JavaScript Library
Unfortunately, the mechanism for the loadInline param tag is rather
ugly ... the HTML specification causes a few problems for us.
The HTML specification requires that newline characters get removed
(and carriage-return characters get turned into spaces) before
the parameter string is passed to the applet. Therefore, the browser
removes the newline characters before they get sent to the applet.
Jmol has a special syntax to work around this issue.
you put a vertical bar beginning of each line ... like this:
...
<param name="loadInline" value="
|put your
|molecular model
|data here
" />
The JmolApplet will replace the vertical bars with a newline character.
(Any white space up through the first vertical bar is removed).
If you have a text string with the molecular model and you want to
convert it, you can use a regular expression to perform the substitution.
Different OS platforms use different conventions for line termination, so
your code should check for three different end-of-line sequences ...
carriage-return, linefeed, or
carriage-return linefeed.
In Perl:
myMolecularModel ~= s/\r|\n|\r\n/|/g;
In JavaScript:
myMolecularModel.replace(/\r|\n|\r\n/g, "|");
When you issue the script the command show orientation
it outputs three axis rotations that will return the molecule
to its current orientation. This type of rotational orientation in
3-space is known as an Euler Angle.
Unfortunately, there are several different conventions for
Euler Angles. The most common are Z-X-Z (the x-convention) and
Z-Y-Z (the y-convention). The Z-Y-Z (y-convention) is generally
followed in in quantum mechanics. Therefore, Jmol uses the y-convention.
For more info see
http://www.algebra.com/algebra/about/history/Euler-angles.wikipedia
http://mathworld.wolfram.com/EulerAngles.html
http://casgm3.anorg.chemie.uni-tuebingen.de/klaus/nmr/conventions/euler/euler.html
|