### Section 4.8.5.5.6
Using a Coloured Dust

If we want to create a colored dust we can easily do this by using a non-white color in the halo's color map. In this case we'll also have to set the filter channels in the color map to non-zero values to specify the amount of light that will be filtered by the dust's color.

We use the following color map to get a partially filtering, red dust for example:

      colour_map {
        [ 0 color rgbft <1, 0, 0, 0.5, 1.0> ]
        [ 1 color rgbft <1, 0, 0, 0.5, 0.7> ]
      }

### Section 4.8.5.6
Halo Pitfalls

Due to the complexity of the halo feature and the few experiences people have made so far there are a lot of things still to discover.

Some of the most common problems and pitfalls are described below to help us avoid the most common problems.

### Section 4.8.5.6.1
Where Halos are Allowed

As mentioned above a halo completly fills the interior of an object. Keeping this in mind it is reasonable that the following example does not make sense.

      sphere { 0, 1
        pigment {
          checker
          texture {
            pigment { color Clear }
            halo { ... }
          }
          texture {
            pigment { color Red }
          }
        }
        hollow
      }

What's wrong with this example? It's simply that a halo is used to describe the interior of an object and that one cannot describe this interior by describing how the surface of the object looks like. But that's what was done in the example above. We cannot imagine what the interior of the sphere will look like. Will it be filled completey with the halo? Will there be areas filled by the halo and some filled by air? How will those areas look like?

We won't be able to tell the interior's properties from looking at the surface. It's just not possible. This should always be kept in mind.

If the above example was meant to create a sphere filled with a halo and covered with a checker board pattern that partially hid the halo we would have used the following syntax:

      sphere { 0, 1
        pigment {
          checker
          texture {
            pigment { color Clear }
          }
          texture {
            pigment { color Red }
          }
        }
        halo { ... }
        hollow
      }

A halo is always applied to an object in the following way:

      OBJECT {
        texture {
          pigment { ... }
          normal { ... }
          finish { ... }
          halo { ... }
        }
        hollow
      }

There's no halo allowed inside any pigment statement, color map, pigment map, texture map, material map, or whatever. We are not hindered to do this but we will not get what we want.

We can use halos with a layered textures as long as we make sure that the halos are only attached to the lowest layer (this layer has to be partially transparent to see the halo of course).

### Section 4.8.5.6.2
Overlapping Container Objects

POV-Ray is not able to handle overlapping container objects correctly. If we create two overlapping spheres that contain a halo we won't get correct results where the spheres overlap. The halo effect is calculated independently for each sphere and the results are added.

If we want to add different halos we have to put all halos inside a single container object to make sure the halo is calculated correctly (see also "Multiple Halos").

We should also note that non-overlapping, stacked halo containers are handled correctly. If we put a container object in front of another container object the halos are rendered correctly.

### Section 4.8.5.6.3
Multiple Attenuating Halos

It is currently not possible to use multiple attenuating halos with different color maps. The color map of the last halo will be used for all halos in the container object.

### Section 4.8.5.6.4
Halos and Hollow Objects

In order to correctly render halo effects we have to make sure that all objects the camera is inside are hollow. This is done by adding the hollow keyword.

For a detailed explanation see "Empty and Solid Objects".

### Section 4.8.5.6.5
Scaling a Halo Container

If we scale a halo container object we should keep in mind that it makes a great difference where we place the scale keyword.

Scaling the object before the halo statement will only scale the container object not the halo. This is useful if we want to avoid that the surface of the container object becomes visible due to the use of turbulence. As we have learned in the sections above particles may move out of the container object - where they are invisible - if turbulence is added. This only works for spherical and box mapping because the density fields described by the other mapping types don't have finite dimensions.

If the scale keyword is used after the halo statement both, the halo and the container object, are scaled. This is useful to scale the halo to our needs.

The halo keeps its appearance regardless of the transformations applied to the container object (after the halo), i.e. the halo's translucency, color and turbulence characteristics will not change.

### Section 4.8.5.6.6
Choosing a Sampling Rate

Normally we will start with a low sampling rate and we willl only increase it if any aliasing artifacts show up (and don't vanish by using super-sampling and jittering).

The halo's appearance is independent from the sampling rate as long as there are enough samples to get a good estimate of what the halo really looks like. This means that one or two samples are hardly ever enough to determine the halo's appearance. As we increase the number of samples the halo will quickly approach its real appearance.

To put it in a nutshell, the halo will not change its appearance with the sample rate as long as we have a sufficient number of samples and no aliasing artifacts occur.

### Section 4.8.5.6.7
Using Turbulence

As noted in one of the above sections turbulence will have no effect if the constant density function is used (keyword constant). It doesn't matter how much or where we move a point if the density is constant and thus does not depend on the location of the point. We'll get the same density value for all location.

Whenever we add turbulence to a halo we must not use the constant density function.

### Section 4.9
Working With Special Textures

Many of the pigment patterns we have seen elsewhere in POV-Ray make use of a color_map statement to blend different colors together. Depending on how we list the entries of the color map, we can fade gradually from one color to the next, or have it abruptly make the transition from one to the next. In fact, the color map is a powerful tool for customizing the various pigment patterns, which requires a bit of practice to learn to use it correctly. And all that's fine, when it's just individual colors we want to use. But what if we could blend entire pigment patterns, normal patterns, or whole other textures? Starting with POV-Ray 3, we can!

In order to experiment with some of the exciting new texturing options, let us set up a basic scene file, into which we will be plugging the example textures to experiment with later. So to begin, we set up the following basic include files, a camera and a light source.

      #include "colors.inc"
      #include "textures.inc"

      camera {
        orthographic
        up <0, 5, 0>
        right <5, 0, 0>
        location <0, 0, -25>
        look_at <0, 0, 0>
      }

      light_source { <100, 100, -100> color White }

### Section 4.9.1
Working With Pigment Maps

Starting with something simple, let's look at the pigment map. We must not confuse this with a color map, as color maps can only take individual colors as entries in the map, while pigment maps can use entire other pigment patterns. To get a feel for these, let's begin by setting up a basic plane with a simple pigment map. Now, in the following example, we are going to declare each of the pigments we are going to use before we actually use them. This isn't strictly necessary (we could put an entire pigment description in each entry of the map) but it just makes the whole thing more readable.

      // simple Black on White checkboard... it's a classic
      #declare Pigment1 = pigment {
        checker color Black color White
        scale .1
      }

      // kind of a "psychedelic rings" effect
      #declare Pigment2 = pigment {
        wood
        color_map {
          [ 0.0 Red ]
          [ 0.3 Yellow ]
          [ 0.6 Green ]
          [ 1.0 Blue ]
        }
      }

      plane { -z, 0
        pigment {
          gradient x
          pigment_map {
            [ 0.0 Pigment1 ]
            [ 0.5 Pigment2 ]
            [ 1.0 Pigment1 ]
          }
        }
      }

Okay, what we have done here is very simple, and probably quite recognizable if we have been working with color maps all along anyway. All we have done is substituted a pigment map where a color map would normally go, and as the entries in our map, we have referenced our declared pigments. When we render this example, we see a pattern which fades back and forth between the classic checkerboard, and those colorful rings. Because we fade from Pigment1 to Pigment2 and then back again, we see a clear blending of the two patterns at the transition points. We could just as easily get a sudden transition by amending the map to read.

      pigment_map {
        [ 0.0 Pigment1 ]
        [ 0.5 Pigment1 ]
        [ 0.5 Pigment2 ]
        [ 1.0 Pigment2 ]
      }

Blending individual pigment patterns is just the beginning.

### Section 4.9.2
Working With Normal Maps

For our next example, we replace the plane in the scene with this one.

      plane { -z, 0
        pigment { White }
        normal {
          gradient x
          normal_map {
            [ 0.0 bumps 1 scale .1]
            [ 1.0 ripples 1 scale .1]
          }
        }
      }

First of all, we have chosen a solid white color to show off all bumping to best effect. Secondly, we notice that our map blends smoothly from all bumps at 0.0 to all ripples at 1.0, but because this is a default gradient, it falls off abruptly back to bumps at the beginning of the next cycle. We Render this and see just enough sharp transitions to clearly see where one normal gives over to another, yet also an example of how two normal patterns look while they are smoothly blending into one another.

The syntax is the same as we would expect. We just changed the type of map, moved it into the normal block and supplied appropriate bump types. It is important to remember that as of POV-Ray 3, all patterns that work with pigments work as normals as well (and vice versa, of course) so we could just as easily have blended from wood to granite, or any other pattern we like. We experiment a bit and get a feel for what the different patterns look like.

After seeing how interesting the various normals look blended, we might like to see them completely blended all the way through rather than this business of fading from one to the next. Well, that is possible too, but we would be getting ahead of ourselves. That is called the average function, and we will return to it a little bit further down the page.

### Section 4.9.3
Working With Texture Maps

We know how to blend colors, pigment patterns, and normals, and we are probably thinking what about finishes? What about whole textures? Both of these can be kind of covered under one topic. While there is no finish map per se, there are texture maps, and we can easily adapt these to serve as finish maps, simply by putting the same pigment and/or normal in each of the texture entries of the map. Here is an example. We eliminate the declared pigments we used before and the previous plane, and add the following.

      #declare Texture1 = texture {
        pigment { Grey }
        finish { reflection 1 }
      }

      #declare Texture2 = texture {
        pigment { Grey }
        finish { reflection 0 }
      }

      cylinder { <-2, 5, -2>, <-2, -5, -2>, 1
        pigment { Blue }
      }

      plane { -z, 0
        rotate y * 30
        texture {
          gradient y
          texture_map {
            [ 0.0 Texture1 ]
            [ 0.4 Texture1 ]
            [ 0.6 Texture2 ]
            [ 1.0 Texture2 ]
          }
          scale 2
        }
      }

Now, what have we done here? The background plane alternates vertically between two textures, identical except for their finishes. When we render this, the cylinder has a reflection part of the way down the plane, and then stops reflecting, then begins and then stops again, in a gradient pattern down the surface of the plane. With a little adaptation, this could be used with any pattern, and in any number of creative ways, whether we just wanted to give various parts of an object different finishes, as we are doing here, or whole different textures altogether.

One might ask: if there is a texture map, why do we need pigment and normal maps? Fair question. The answer: speed of calculation. If we use a texture map, for every in-between point, POV-Ray must make multiple calculations for each texture element, and then run a weighted average to produce the correct value for that point. Using just a pigment map (or just a normal map) decreases the overall number of calculations, and our texture renders a bit faster in the bargain. As a rule of thumb: we use pigment or normal maps where we can and only fall back on texture maps if we need the extra flexibility.

### Section 4.9.4
Working With List Textures

If we have followed the corresponding tutorials on simple pigments, we know that there are three patterns called color list patterns, because rather than using a color map, these simple but useful patterns take a list of colors immediately following the pattern keyword. We're talking about checker, hexagon, and, new to POV-Ray 3, the brick pattern.

Naturally they also work with whole pigments, normals, and entire textures, just as the other patterns do above. The only difference is that we list entries in the pattern (as we would do with individual colors) rather than using a map of entries. Here is an example. We strike the plane and any declared pigments we had left over in our last example, and add the following to our basic file.

      #declare Pigment1 = pigment {
        hexagon
        color Yellow color Green color Grey
        scale .1
      }

      #declare Pigment2 = pigment {
        checker
        color Red color Blue
        scale .1
      }

      #declare Pigment3 = pigment {
        brick
        color White color Black
        rotate -90*x
        scale .1
      }

      box { -5, 5
        pigment {
          hexagon
          pigment {Pigment1}
          pigment {Pigment2}
          pigment {Pigment3}
          rotate 90*x
        }
      }

We begin by declaring an example of each of the color list patterns as individual pigments. Then we use the hexagon pattern as a pigment list pattern, simply feeding it a list of pigments rather than colors as we did above. There are two rotate statements throughout this example, because bricks are aligned along the z-direction, while hexagons align along the y-direction, and we wanted everything to face toward the camera we originally declared out in the -z-direction so we can really see the patterns within patterns effect here.

Of course color list patterns used to be only for pigments, but as of POV-Ray 3, everything that worked for pigments can now also be adapted for normals or entire textures. A couple of quick examples might look like

      normal {
        brick
        normal { granite .1 }
        normal { bumps 1 scale .1 }
      }

or...

      texture {
        checker
        texture { Gold_Metal }
        texture { Silver_Metal }
      }

### Section 4.9.5
What About Tiles?

In earlier versions of POV-Ray, there was a texture pattern called tiles. By simply using a checker texture pattern (as we just saw above), we can achieve the same thing as tiles used to do, so it is now obsolete. It is still supported by POV-Ray 3 for backwards compatibility with old scene files, but now is a good time to get in the habit of using a checker pattern instead.

Next Section
Table Of Contents