Section 4.8.5.5.4
Making the Shadows Look Good

In order to reduce the aliasing artefacts 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 the regular aliasing artefacts 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 you should always try to use the other methods first. If they don't suffice you'll have to increase the sampling rate.

We use the following halo to reduce the aliasing artefacts ( 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 artefacts 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 disribution 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.

You 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 on direction only (e.g. turbulence <0.2, 1, 0.2> ).

Section 4.8.5.5.6
Using a Coloured Dust

If you want to create a colored dust you can easily do this by using a non-white color in the halo's color map. In this case you'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.

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 in order to help you to 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 you cannot describe this interior by describing how the surface of the object looks like. But that's what was done in the example above. Can you 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?

You 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 you 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. You are not hindered to do this but you will not get what you want.

You can use a halo with a layered textures as long as you 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 you create two overlapping spheres that contain a halo you won't get correct results where the spheres overlap. The halo effect is calculated independently for each sphere and the results are added.

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

You should also note non-overlapping, stacked halo containers are handled correctly. If you 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 you want to avoid that the surface of the container object becomes visible due to the use of turbulence. As you've 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 your 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 you'll start with a low sampling rate and you'll only increase it if any aliasing artefacts turn 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 you 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 you have a sufficient number of samples and no aliasing artefacts occur.

Next Section
Table Of Contents