1. Object copying
2. The power of template surfaces

So far we've seen the rules on how using a GRASP surface to display a single object and a single property. Now let's see how to use several surfaces at the same time, and possibly showing different properties.

As any other standard object, a grasp_surface object can be declared as a variable and "cloned" using different transformations. The variable is defined through standard #declare or #local directives, and it is not rendered until you create some object with it:

Object copying
test01.p4g  scene.inc  crambin.srf.gz #version 3.1; #include "scene.inc" #declare surf = grasp_surface { "crambin.srf" colored_by curvatures range <-50,0,10> finish{ diffuse 0.6 specular 0.75 roughness 0.005 } scale <1,1,-SYSTEM> correct_translate(-11,-10.5,0) } object{ surf correct_translate(-8,-1, -50) } object{ surf rotate y*180 correct_translate(22,12,-250) }

Here we created two copies of the same object, and placed them at different positions in space after applying a 180 degrees rotation (around the y axis) for the second. Again, the first grasp_surface object is not displayed since it is only a variable definition.

Now imagine we want to show several properties mapped on the same surface. The obvious solution would be to setup two different grasp_surface objects using the same "crambin.srf" file and mapping the required property. In this case it means we use the same surface twice. For small molecular surfaces as in this tutorial it's not critical, but it really is for huge surfaces (see the F1 ATPase example).

Hence, in order to save memory (and also parsing time), it's possible to map different properties on copies of the same object, which is thus called a template surface. This feature is quite different from what is possible to do in POV-Ray, where you would have to read a second surface with appropriate textures. To define a template, declare a grasp_surface variable first. Then use this variable within another grasp_surface object definition through the with option:

The power of template surfaces
test02.p4g  scene.inc  crambin.srf.gz #version 3.1; #include "scene.inc" #declare surf = grasp_surface { "crambin.srf" finish{ diffuse 0.6 specular 0.75 roughness 0.005 } scale <1,1,-SYSTEM> correct_translate(-11,-10.5,0) } grasp_surface { "crambin.srf" with surf colored_by potentials gradient rgb<1,0,0>, rgb 1 transmit 0.9, rgbf<0,0,1,0.9> range <-3,-1.5,2> pigment{ color rgbt 1 } correct_translate(-8,-1,-50) } grasp_surface { "crambin.srf" with surf colored_by curvatures range <-50,0,10> rotate y*180 correct_translate(22,12,-250) }

You may notice that the textures (e.g. the finish looking) and transformations defined in the template surface are inherited in the copies as expected. The first copy, being partly transparent, uses a pigment definition to setup a global transparency and to cast correct shadows on the floor. The second is fully opaque, so it does not need this statement.

Remember that the surface filename is mandatory in any grasp_surface definition. In the case of a template definition, the GRASP filename is used to read the surface coordinates and possibly an associated property. For copies using a template surface, this filename allows to read and to map a different property if available. Hence, the surface files for the template and its copies should be the same, or at least have the same number of vertices.

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