The goal is obviously to make the output as similar as possible in different output modes. However, completely identical output is difficult to obtain. There are cases when the implementation of a particular command or state parameter is too difficult or would be very inefficient for a particular output format.
Sometimes a particular output format has special features which are quite useful. These features may be used by MolScript, even if there is no counterpart in the other output formats. One such example is the anchor command which is meaningful only in the VRML 2.0 output format.
The hidden-surface algorithm in the PostScript mode relies on the graphical segments being sufficiently small. The introduction of some new commands, e.g. cylinder and object, have necessitated the addition of the segmentsize parameter which controls the subdivision of certain graphical segments. Another addition is the labelbackground parameter which is useful for labels in cluttered regions of the image.
Transparency and explicit light sources have not been implemented for PostScript in the current version of MolScript.
In previous versions of MolScript (v1.4 and older), the Encapsulated PostScript (EPS) format was exactly identical to the PostScript output, apart from a few lines of output code. However, this caused considerable confusion, since much software (desktop publishing and other office applications) apparently seems to assume the existence of a pixmap in an EPS file. In this version of MolScript, the EPS implementation is completely new and has now been decoupled from the PostScript implementation. This is a major departure from the policy of backwards compatibility, but since the EPS format in v1.4 (and older) was such a fiasco, it was time to bite the bullett.
MolScript produces an input file for the render program,
which produces an image file in either SGI (aka RGB) format, or TIFF
format, depending on how you compiled the Raster3D
package. Version 2.4b (or later) of Raster3D is required for
use with MolScript v2.0.2.
It is now possible to output labels to the Raster3D file, provided that you have compiled MolScript with the GLUT library.
MolScript now allows a larger degree of control over the values written to the header section of the Raster3D input file, mainly through the command-line options. This includes the size of the image (in pixels), the aliasing scheme and the background colour.
However, it is still possible to use a manually edited header section,
by having a file called header.r3d present in the
directory where MolScript is executed. The content of this file must
be valid for the render program of Raster3D; MolScript
does not check its contents. If it is present, MolScript will use this
header file instead of generating the header directly.
Note: The header file feature was kept just for backwards compatibility, and may be removed in future versions. It is badly designed.
The control of the light source features is incomplete for the Raster3D format. This is largely due to the inherent limitations of the Raster3D lighting model.
Warning: There may be changes in the implementation of the lighting parameters for the Raster3D output mode in future versions of MolScript.
The ability to use Web links and behaviours in VRML opens the avenue for creating quite content-rich and informative 3D models of molecules, especially such complex entities as proteins. It was clear from the start that the graphical entities in MolScript were eminently suitable for conversion into VRML models. The development of MolScript v2.0 was, in fact, the response to the challenge to this challenge.
The current version of MolScript contains support for the output of all graphical objects and also Web links (anchors). Experimental implementations of features to support dynamical behaviour in VRML have been made, and some are actually present in the current version. However, since these features are just experimental it is highly likely that they will change in design and implementation, and it was therefore decided to let these features remain undocumented, so as to avoid future confusion in the user community.
The GLUT library is used for the windowing functions, and is the basis for the user interaction which occurs via the mouse. The mouse buttons have the following functions:
| mouse button | action |
|---|---|
| left button | rotate |
| Shift + left button (up-down) | scale |
| Shift + middle button (up-down) | change slab |
| right button | menu choice |
The menu choices available through the right mouse button are activated by holding down the button, moving it over the option so that it becomes highlighted, and then releasing the button. The available menu items are:
| menu item | action |
|---|---|
| "Full screen" | The window is enlarged to fill the entire screen, its borders are removed, and it is stacked on top of all other windows. The exact action depends on the window system of your computer. The menu option is changed to "Normal window" (see below). |
| "Normal window" | The window is reduced back to the its original size, with normal borders. The menu option is changed back to "Full screen" (see above). |
| "Output view" |
Output to the stderr (standard error) the current values
for the window and
slab parameters, and the transformation
matrix to be used in a
transform command applied to
all atoms to give the current view of the molecule. This feature
allows the user to find a good view in an interactive fashion. The
output text can be cut-and-pasted into the input file.
|
| "Reset view" | Reset the view parameters (see above) to the original values before the interactive changes made by the user. |
| "Re-read input file" | Read the input file again, as if the program had been started from scratch. This allows the user to modify the input file using a text editor, and then quickly view the effect of the changes. If an error is encountered in the input file, then interpretation of it stops, but the graphics objects rendered so far should be visible. |
| "Quit" | Quit the current session. |
The image is created via the OpenGL rendering system in exactly the same way as the interactive OpenGL mode, except that the image is rendered to a pixmap in memory instead of a window on the display. The pixmap is read off and written to a file having the requested format. The rendering is exactly identical for all image file formats.
The image is therefore exactly identical for the same input file for the image files as for the interactive OpenGL mode, except for any compression algorithm that may be applied as the output file is written. This depends on the image file format.
The SGI image format is in principle specific to SGI IRIX machines, but it is used in some software on other systems as well.
The implementation in MolScript relies on no third-party software, only on a package that is part of the MolScript distribution. This package is based on the published specification of the SGI image file format.
Note that this EPS implementation is quite different from that in the previous versions of MolScript (v1.4 and older). This is a proper pixmap encoding, while the previous versions were basically just ordinary PostScript files with a few small differences.
Unfortunately, JPEG was designed mainly with real-world pictures in mind, so the compression algorithm used is not optimal for the kinds of images rendered by MolScript. The main problem arises for large surfaces with very homogenous colours. These may look blotchy, particularly if a low quality parameter is used.
The implementation relies on publicly available source code libraries.
The PNG image format is intended as a replacement for both the patent-afflicted GIF format and the JPEG format. New Web browsers are supposed to support PNG. The VRML 2.0 specification requires support for PNG images.
The implementation relies on publicly available source code libraries.