1. Discrete colors on the surface
2. Setting a global transparency
3. Reading a color description file

Another possibility is to color the surface with unique colors that have been assigned to the surface. This is the case for instance when you want to hilight the accessible surface of important residues. To do this in Pov4Grasp we use the colored_by discretecolors option:

Discrete colors on the surface
test01.p4g  scene.inc  crambin.srf.gz #version 3.1; #include "scene.inc" grasp_surface { "crambin.srf" colored_by discretecolors finish{ diffuse 0.6 specular 0.75 roughness 0.005 } scale <1,1,-SYSTEM> correct_translate(-11,-10.5,0) }

The example shows a set of 4 different residue types: some are red, others are green or cyan, while the rest of the surface stays white by default. Using the discretecolors property allows to map up to 99 colors on the surface.

As explained in the previous part, we can also specify a transparency amount to the surface through direct filter or transmit statements. So let's see what makes the differences between the two variants:

Setting a global transparency
test02.p4g  test03.p4g  scene.inc  crambin.srf.gz Defining a filtering transparency: #version 3.1; #include "scene.inc" grasp_surface { "crambin.srf" colored_by discretecolors filter 0.9 pigment{ color rgbt 1 } finish{ diffuse 0.6 specular 0.75 roughness 0.005 } scale <1,1,-SYSTEM> correct_translate(-11,-10.5,0) } Defining a transmitting transparency: #version 3.1; #include "scene.inc" grasp_surface { "crambin.srf" colored_by discretecolors transmit 0.9 pigment{ color rgbt 1 } finish{ diffuse 0.6 specular 0.75 roughness 0.005 } scale <1,1,-SYSTEM> correct_translate(-11,-10.5,0) }

Well, the pictures don't really rock... The first one gives dark area due to the subsequent filtering of primary colors, while the second is almost white and would require a lower transparency value (e.g. 0.5) to enhance the colors. A possible workaround could be to define variable transparency amounts as we can do when mapping another property such as electrostatic potentials.

This is exactly what we can do ! However the method differs since defining a color gradient simply has no meaning in this case (the gradient and range option are ignored). Hence to change the color definitions, we have to read a color description file, as this one. GRASP allows you to write such files for instance when you create custom colors in your session. It consists in 99 lines giving the three color components in the reverse RGB order, i.e. Blue Green Red. Usually the last 9 lines are copies of the first ones (default colors). In our example, we slightly changed this file such as to add transparency data to specific colors (see below). Then it is read when invoquing the colors_file option (formerly with sub-option):

Reading a color description file
test04.p4g  scene.inc  crambin.srf.gz #version 3.1; #include "scene.inc" grasp_surface { "crambin.srf" colored_by discretecolors transmit 0.9 colors_file "defcol.dat" pigment{ color rgbt 1 } finish{ diffuse 0.6 specular 0.75 roughness 0.005 } scale <1,1,-SYSTEM> correct_translate(-11,-10.5,0) }

The data we added in the file are simply two integers which correspond to the filter and transmit components respectively. In GRASP the colors are assigned with components in the 0..255 range, so the added components use the same rules for consistency, instead of the expected 0..1 values. Our custom defcol.dat file has been modified as following:

  255  255  255              /* white   */
    0    0  255    0    0    /* red     */
    0  255    0  127    0    /* green   */
  255    0    0              /* blue    */
  255    0  255              /* magenta */
  255  255    0    0  127    /* cyan    */
    0  255  255              /* yellow  */
  125  125  125              /* gray    */
  200  100   50              /* "navy"  */

Page last updated: Jun 20, 2002 Any comment or suggestion ?