The primary purpose of shadowing is to convey a feeling of depth in the rendered image. This can be particularly effective when there are a relatively small number of elements in the scene, or when there is a grouping of foreground objects which cast shadows onto a separate grouping of background objects. However if there are a large number of elements in the scene, e.g. a ribbon and arrow representation of a large molecular assembly, the use of shadows may actually complicate the visual impact and make the image less satisfactory. In this case you may wish to try rendering the image both with and without shadows, or you might experiment with the location of the primary light source (the SOURCE parameter in the 12th header record input to render). Finally, you can de-emphasize the shadows by increasing the secondary (straight-on) light source contribution parameter STRAIT.
The quality of pictures generated by Raster3D is ultimately limited by the output device. Although you will probably compose and preview your figures on a workstation screen, you will probably want to re-render the final version with a larger number of pixels before sending it to a film recorder or high performance color printer. For example, a typical film recorder can produce slides with a resolution of roughly 4000x3000 pixels (much larger than can be displayed on a workstation screen). The number of pixels in your rendered image is controlled by the parameters (NTX,NTY) and (NPX,NPY) in the 2nd and 3rd header records input to the render program, or by the -size command line option to render. If you need to convert your image to PostScript so that you can send it to a PostScript printer (the only time you should ever convert to PostScript!) then read the section on PostScript conversion below. You should also be aware that color balance and particularly the appropriate ``gamma correction'' varies from one device to another. The Raster3D render program can apply a gamma correction or you can apply one afterwards to the generated image files using a general purpose image processing program (e.g. the ImageMagick "mogrify" command). If you will be using a particular output device regularly, it is worth an initial round of experimentation to determine the best gamma value for future runs. The appropriate gamma correction can then be applied to each rendered picture before sending it for printing.
So long as you stick to a consistent coordinate system, you can build up a complex Raster3D scene from bits and pieces created by various different tools and programs. For example, you could create a scene that is defined by a viewpoint selected interactively in Xfit, and that contains a protein molecule drawn by Molscript, a molecular surface drawn by GRASP, and a "floor" or bounding box from the Raster3D library of pre-described objects. This scene can conveniently be described to the render program by using file indirection in the input stream, which might look something like this:
# # Header records written from inside Xfit @viewpoint.r3d # # Molscript V2.0 output file @secondary-structure.r3d # # Make the molecular surface (from GRASP via ungrasp) # transparent by using a material definition # from the Raster3D library $R3D_LIB @transparent.r3d @surface.r3d @end_material.r3d # # Add a few extra goodies @red.r3d @floor.r3dThis makes it very easy to experiment with your composition without having to edit huge input files. You could, for example, change the color of the floor by substituting the library file blue.r3d for the file red.r3d. Or you could render the same scene from a different viewpoint by changing the view matrix in viewpoint.r3d. Even better, you could select from a number of pre-defined views described by header records in files view1.r3d, view2.r3d, view2.r3d, and so on just by making viewpoint.r3d be a symbolic link to the particular view you want to render. That way you needn't edit any input files at all to shift the scene. This approach is particularly useful for producing animation.
The EYEPOS parameter input to the render program specifies a viewing distance for the resulting image. You may think of this as equivalent to the distance between a camera and the object being photographed. EYEPOS = 4 means that the distance from the camera to the center of the object is four times the width of the field of view. Generally the sense of depth conveyed by the rendered image is slightly increased by positioning the virtual camera reasonably close to the object. However, if you are composing a figure containing two or more similar objects which are next to each other, e.g. a comparison of two variants of the same protein structure, then the resulting parallax may be more of a hindrance than a help. Since the virtual camera is centered, it will ``see'' the right hand object slightly from the left, and the left hand object slightly from the right. This results in different effective viewpoints for paired objects which would otherwise be identical. To overcome this effect you may wish to set EYEPOS to 0.0, which disables all perspective and parallax. The same considerations apply for the production of stereo pairs.
All Raster3D objects emitted by a Molscript run are placed into a single scene description. That is, the pairs of ``plot'' and ``end plot'' statements in a Molscript input file have no effect in Raster3D mode. Therefore a Molscript file which describes a stereo pair as two separate plots will not work correctly when fed through to render. You should instead use Molscript to produce a single [mono] scene description for Raster3D, and run it through the stereo3d script to produce a stereo pair. Here is an example:
# # Use molscript to generate a Raster3D input file # molscript -r < image.mol > image.r3d # # Render image once to check that it's what we want # render -tiff mono.tiff < image.r3d # # Render it again, this time as a stereo pair # stereo3d -tiff stereo.tiff < image.r3d
A clipping plane restricts the contents of the rendered image based on the Z coordinate of individual objects. There is both a front clipping plane and a rear clipping plane. Objects closer to the viewer than the front plane are not rendered, and objects further from the viewer than the rear plane are not rendered. The Z-coordinate of the clipping plane must specified in the same units as coordinates of your input objects, so if you are working in PDB coordinates you should specify the clipping planes in Ångstroms. Raster3D allows two different methods of setting clipping planes with slightly different effects. Clipping planes specified as a global property apply to all objects in the image. An object is discarded on input if all of its vertices lie outside the clipping plane; a clipped object is entirely omitted, an unclipped object is entirely rendered even if part of it extends beyond the clipping plane. An example of specifying global clipping planes is given below:
# set global clipping planes 16 FRONTCLIP 2. 16 BACKCLIP 10.The other option is to assign clipping planes as part of defining a set of special material properties. In this case the clipping planes are applied only to objects within the begin/end scope of the special material. In this case the clipping is done on a pixel-by-pixel basis, which means that individual objects may be rendered in part only. The portion of the object that extends beyond the clipping plane is omitted from the rendered image. An example of a material specification that includes a front clipping plane is given below:
# Opaque material with specular properties inherited from header # Extra record present to specify clipping plane 8 -1.0 -1.0 1.0 1.0 1.0 0.0 0 0 0 1 FRONTCLIP 2.
Bounding planes are a more general case of Z-clipping planes. They differ from Z-clipping planes as follows:
The current implementation allows two slightly different variations in how multiple bounding planes interact with each other. One variant is used to draw ortep-like thermal ellipsoids in which one octant is cut away. In this case a given volume is excluded from rendering only if it is `above' all bounding planes associated with its material definition; exclusion requires a logical AND of three bounding planes. Here is the specification for one such ortep-like ellipsoid. Note that all three bounding planes pass through the center of the ellipsoid, and a single color specification is given for all three bounding surfaces (-fancy6 option to rastep). If no BOUNDING_COLOR is specified, then the exposed surface is rendered using the base color of the materiall; if you like, you can specify a new BOUNDING_COLOR for each plane.
# Thermal ellipsoids from Rastep Version V2.6d
# Probability level 0.50
8
-1.0 -1.0 -1.0 -1.0 -1.0 0.0 0 0 0 5
ORTEP_LIKE
BOUNDING_COLOR 0.500 0.500 0.500
BOUNDING_PLANE 0 24.274 47.792 19.835 0.8259 0.5467 0.1376
BOUNDING_PLANE 0 24.274 47.792 19.835 -0.4475 0.7843 -0.4297
BOUNDING_PLANE 0 24.274 47.792 19.835 -0.3428 0.2934 0.8924
14
24.274 47.792 19.835 0.893 0.7 0.7 0.7
8.6581 6.0432 5.0725 2.9042 0.8405 0.3715 0.0 0.0 0.0 -2.3661
In the absence of the ORTEP_LIKE restriction, multiple bounding planes are
combined using a logical OR. A given volume is exluded from rendering if
it is clipped by one or more of the associated bounding planes. This
could be used, for example, to render a central slice from an extended
structure or a single wedge from a sphere.
Creating your own colour descriptions
The Raster3D distribution contains a number of
pre-defined colouring schemes (e.g. the shapely.colours file, cpk.colours, and
mycolors.pdb). If you choose to modify these, or create your own, then you
should be aware that render works internally with the square root of the
specified colour values (yes it's a very strange concept!).
To convert a normal
RGB colour triple into a Raster3D color specification it is therefore necessary
to square each component. For example, to specify a half-intensity yellow you
would square the components of the pure RGB triplet (0.5, 0.5, 0.0) to yield
(0.25, 0.25, 0.0) in the COLOUR record input to render. The Raster3D output
option to Molscript performs this conversion automatically, so you should not
have to alter the colour specifications to switch between PostScript and
Raster3D modes.
The HTML tool r3d_colorpicker provides
an interactive colour previewer.
Suppose you are already working in some interactive graphics program, and want to reproduce the current viewpoint/orientation for a Raster3D picture. If the program will dump the current view matrix then you will probably be able to use it as a view matrix for Raster3D also. However many programs (including Molscript) dump a matrix which is the transpose of the matrix used by Raster3D.
Users of Alwyn Jones' program O should obtain a copy of the program o2mol from the O ftp site. Once you have composed your view in O you can convert to a Molscript/Raster3D viewpoint description by dumping the O datablock named .GS_REAL
O> write_form .gs_real omatrix.dat Heap> Format: <cr>followed by a shell command
o2mol < omatrix.dat > o2mol.outThe file o2mol.out will now contain instructions for reproducing the O viewpoint in Molscript. Also, the 3x3 matrix which o2mol gives as ``for coordinate transforms'' is in the correct form to use directly as a Raster3D matrix if you aren't processing with Molscript first.
Coot (home page) can create Raster3D input files or images directly from the current screen view.
Duncan McRee's XtalView program ( http://www.sdsc.edu/CCMS/Packages/XTALVIEW/) is another crystalloghic modeling tool that can create Raster3D input files or images directly from the current screen view, including atoms, bonds, view objects, electron density, etc. Many Raster3D rendering options can be varied using control widgets in the Xfit pop-up plotting menus. Xfit can also be used simply to create a set of Raster3D header records describing the current view.
Another interactive tool you might be interested in is the VMD program from the Theoretical Biophysics group at the University of Illinois. VMD provides a wide variety of methods for interactively rendering and coloring a molecule, and can generate a Raster3D input file which will very nearly duplicate the view composed on your workstation screen. A more complete description of VMD is available via the VMD WWW home page.
Coordinate systems:When Molscript runs it normalizes the coordinates of objects in the figure so that they are described by an identity transformation matrix. The 3x3 matrix printed out by Molscript to the terminal is the transpose of that needed by Raster3D programs. Swap the entries about the diagonal from upper left to lower right before copying it into the TMAT header records for render or normal3d.
To normalize other Raster3D input files describing objects still in the original PDB coordinate space (so that they can be merged with your Molscript output), replace the four TMAT records in the header with a new matrix built as below and then feed the resulting file through normal3d.
| Transpose of 3x3 Molscript matrix | |||
|---|---|---|---|
| a11 | a12 | a13 | 0. |
| a21 | a22 | a23 | 0. |
| a31 | a32 | a33 | 0. |
| Translation components | Scale | ||
| T1 | T2 | T3 | S |
This used to be a pain to do. Now there is an easy answer: get Molscript version 2. The old, laborious, procedure may still be informative as an example of mixing PostScript and Raster3D, however. Here is a summary of how to do it if you really want to.
It is possible to use a general image processing program (e.g. ImageMagick) to convert a color figure to a monochrome figure. In general a straight conversion will produce an image which is much too dark. In order to improve the result you can try breaking the conversion up into several steps: first convert from full 24-bit color to a smaller number of colors (say 256), next apply a substantial gamma correction (e.g. gamma 2.0) to lighten the image, and finally convert the color image to monochrome being sure to select a dithering option if it is available. Some experimentation with this process can produce acceptable, although not ideal, monochrome images suitable for printing on a standard laser printer. You may have to repeat the color reduction and gamma correction steps before finally converting to monochrome. Better results can be obtained by using the auxiliary program avs2ps as a filter. This utility will convert any AVS-format image, including the default output stream from render, directly into a dithered black & white PostScript image. As of this writing the avs2ps program is included with the Raster3D distribution.
Do not convert your raster image to PostScript unless you really, really have to. This should only happen if you want to send the image to a printer that understands nothing but PostScript. The raster image consists of a certain number of pixels on X and on Y, and the size of each dot depends entirely on the physical resolution of the device the image is displayed on. To produce a Raster3D figure of a given size on a PostScript printer, you must know the physical resolution of the printer. A true PostScript figure would be scalable and device-independent; this will not be true for a raster image forced into a PostScript file. Here are the required steps:
convert -density 300 -geometry 1200x900 -page 1200x900+50+50 image.tiff image.ps
Back to top
Raster3D homepage