Explicit lighting is a new feature in v2 of MolScript. This is a short overview of the parameters that affect lighting. Some other topics involving the appearance of graphics objects are also discussed.
The lighting features in MolScript have been designed such that the default values should give a reasonable appearance for all graphics objects, similar to the image produced by previous versions (v1.4 and older) of MolScript.
The light sources in MolScript are global: A light source created at some point in the input file will illuminate objects which have been created in the same file, no matter where.
There is often a limit to the number of light sources that can be defined in a scene, depending on which output format is used, and which computer system is used to view the resulting scene. For the OpenGL output mode there is a maximum of 8 light sources (including the headlight).
It should be noted that the lighting features apply to graphics objects with surfaces, not to those consisting only of lines, labels or points.
There are three different kinds of light sources:
Some graphics parameters affect all of these, while others affect only one kind of light source. See the descriptions for each kind of light source.
The interplay between the different light source parameters and the surface properties are quite complex, and is not be described here. See the descriptions in the OpenGL Programming Guide (Neider et al 1993) or the Annotated VRML 2.0 Reference Manual (Carey & Bell 1997) for exhaustive descriptions.
A default light called the headlight is defined and switched on, by default. This is a white, directional light source, conceptually located at the position of the viewer, and shining towards the origin. In the current version of MolScript, its properties cannot be changed in any way except being switched on and off.
The inherent colour of a surface is usually equated with the diffuse colour used in lighting calculations.
In MolScript, the diffuse colour is taken from different parameters depending on whether the colourparts parameter is switched on or off.
If colourparts is off (the default), then the diffuse colour is determined by the planecolour, the plane2colour and atomcolour parameters (depending on the graphics object).
If colourparts is switched on, then the diffuse colour is determined by the residuecolour or atomcolour parameters (depending on the graphics object).
The specular colour is the surface property that modulates the colour of light that has conceptually been directly reflected (as in a mirror) by the surface. This is used to model shiny surfaces, such as metals.
The specularcolour determines the specular reflection of a surface regardless of its diffuse colour. It is set to black (that is, no specular colour) by default.
The emissive colour is a colour which is independent of any light sources in the scene. It is used to model glowing objects, or objects whose colour should be independent of any light sources in the scene.
The emissivecolour parameter determines the emissive colour of a surface regardless of its diffuse colour. It is set to black (that is, no emissive colour) by default.
Note that using an emissive colour for an object does not turn it into a light source illuminating other objects in the scene. If you want an atom or another object to actually behave as a light source, then you must create a light source at that position.
Transparent surfaces allow objects which are hidden behind the transparent object to be at least partly visible. This effect can be very useful in many cases. It should be noted that a true transparency calculation is usually rather demanding, so some output formats (VRML 2.0 and OpenGL) rely on approximations which may or may not be adequate.
The transparency parameter affects all graphics objects, including lines, labels and points. The value is by default set to 0.0, which means no transparency.
It has been noted that the VRML 2.0 files display incorrectly in some browsers when partial transparency has been applied. A surface specified with transparency 0.9 is almost completely opaque, when it should be very nearly translucent. This seems to be a bug in some commonly used browsers, and is, as far as is possible to ascertain, not due to MolScript. A value of 0.5 seems to give correct results.
The implementation of lighting in MolScript v2.1 is unfortunately neither complete nor identical in all output formats. The PostScript and Raster3D output modes are the most defective.
The implementations for the OpenGL output and VRML 2.0 output modes are very similar and should be correct.
The PostScript output mode has the largest differences from the ideal, which in part relates to its inherent limitations, and in part to the difficulty of implementation of some of the appearance effects that are easy to produce in the other output modes.
The PostScript output mode has no implementation of light sources or material surface properties. The closest it comes to lighting are the shading and shadingexponent parameters which determine the shading of surfaces as a function of the angle between the surface normal and the view direction. This is in effect a simple calculation of the effects of a headlight.
Another important difference exists compared to the other modes: In PostScript, all graphical objects are delimited by lines drawn around the surfaces. This is very important to create the proper visual effects for the various graphics objects in this output mode. Therefore all graphics state parameters that affect lines (linecolour, linedash and linewidth) also affect the appearance of most other graphical objects. This is not the case for the other output formats.
A related difference is the depthcue parameter, which affects many different objects in the PostScript output mode. It does not affect any other output modes. The basic idea is that the distance from the object to the viewer affects various appearance details, such as the size of labels or the width of lines.
The implementation of lighting in the Raster3D output mode is very limited and partly incorrect. This is to a large extent due to the inherent limitations in the Rasted3D file format.Top page