Section 4.8.5.5.4
Making the Shadows Look Good

In order to reduce the aliasing artifacts we use three different techniques: jittering, super-sampling and an increased overall sampling rate.

The jittering is used to add some randomness to the sampling points making the image look more noisy. This helps because regular aliasing artifacts are more annoying than noise. A low jitter value is a good choice.

The super-sampling tries to detect fine features by taking additional samples in areas of high intensity changes. The threshold at which super-sampling is used and the maximum recursion level can be specified using the aa_threshold and aa_level keywords.

The approach that always works is to increase the overall sampling rate. Since this is also the slowest method we should always try to use the other methods first. If they don't suffice we have to increase the sampling rate.

We use the following halo to reduce the aliasing artifacts (halo34.pov).

box { -1, 1 pigment { colour rgbt <1, 1, 1, 1> } halo { dust dust_type 1 box_mapping constant colour_map { [ 0 color rgbt <1, 1, 1, 1.0> ] [ 1 color rgbt <1, 1, 1, 0.7> ] } samples 50 aa_level 3 aa_threshold 0.2 jitter 0.1 } hollow scale 5 }

Different anti-aliasing methods help to get a satisfying result.

The image looks much better now. There are hardly any aliasing artifacts left.

The same parameters we have used are discussed in the section about the atmosphere feature (see "The Atmosphere" for further explanations).

Section 4.8.5.5.5
Adding Turbulence

The major difference between the halo's dust and the atmosphere described in "The Atmosphere" is the ability to choose a non-uniform particle distribution for the dust. This includes the fact that the halo is limited to a container object as well as the different density mappings and functions.

Another interesting way of getting an irregular distribution is to add some turbulence to the dust. This is done with the turbulence keyword followed by the amount of turbulence to use, like the following example shows (halo35.pov).

box { -1, 1 pigment { colour rgbt <1, 1, 1, 1> } halo { dust dust_type 1 box_mapping linear turbulence 1 colour_map { [ 0 color rgbt <1, 1, 1, 1.0> ] [ 1 color rgbt <1, 1, 1, 0.5> ] } samples 50 aa_level 3 aa_threshold 0.2 jitter 0.1 } hollow scale 5 }

Adding turbulence to the dust makes it much more interesting.

The image we now get looks much more interesting due to the shifts in the particle density.

We should note that we use a linear density function instead of the previous constant one. This is necessary because with a constant density function the density has the same value everywhere. Adding turbulence would have no effect because wherever the points are moved the density will have this same value. Only a non-constant density distribution makes sense when turbulence is added.

The fact that the turbulence value is actually a vector can be used to create effects like waterfalls by using a large turbulence value in one direction only (e.g. turbulence <0.2, 1, 0.2> ).

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.

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.

Next Section
Table Of Contents