1.0 Slime-POV Documentation

Table of Contents

1.1 Enabling Slime-POV Features

In order for any of the features mentioned in this documentation to function, you must put the following line in your source file before any of them are used:

	#version unofficial FLOAT;

Where FLOAT is the version number of POV-Ray that you want to interpret your syntax. Normally, this should be 3.5.

1.2 New Noise Generator Features

1.2.1 Extended Syntax

The Official POV-Ray 3.5 syntax for the noise generators was the keyword noise_generator followed by a single integer from 0 to 3. This could be specified either in a pattern or the global settings block.

Slime-POV extends this syntax in order to allow for new features. The Slime-POV noise generator syntax is as follows:

NOISE_GENERATOR:
	noise_generator {
		NOISE_GENERATOR_IDENTIFIER |
		GENERATOR_TYPE
		[slice FLOAT]
		[repeat INTEGER]
		[match_second_derivatives [Bool]]
	}
GENERATOR_TYPE:
	0 | 1 | 2 | 3 | 4

The old syntax is still supported for backward compatability.

Note that you can #declare noise generators just like you can with pigments, textures, functions, etc.

1.2.2 Noise Generator Type 4

POV-Ray 3.5 allowed 3 types of noise generators: type 1 was implemented in earlier versions of POV-Ray and was somewhat problematic. Type 2 was first implemented in Mega-POV, prior to POV-Ray 3.5, and is the same as type 1, but scaled down to avoid some problems. Type 3 was new in POV-Ray 3.5, and is standard Perlin Noise.

The new type 4 noise generator is similar to type 3, and works the same way internally. The difference is that it is four-dimensional. The value for the fourth dimension can be specified with the slice keyword. This is helpful in animations, where you may want the noise to change smoothly without actually changing its position in 3D space. If you're not going to make use of the 4th dimension, try to avoid using type 4, since it is about twice as slow as type 3, and looks very similar.

A noise generator with type 0 will merely inherit the noise generator specified in global settings, or, if none is specified, type 2 with slice 0, repeat 0, and match_second_derivatives off.

1.2.2.1 Repeating Noise

In addition, the repeat keyword can be used followed by an integer to specify that the function should repeat over the 4th dimension. The repeat keyword only applies to noise generator type 4 and must have an integral value, due to the internal workings of Perlin Noise. Setting repeat to zero (the default) will prevent the noise generator from repeating at all. (Sort of.)

1.2.3 Second Derivative Matching

In Ken Perlin's recent paper, he mentioned a new type of interpolation that matches the second derivatives of the noise function. This significantly reduces a grid artifact when the noise is used as a normal pattern. It is, however, slower to calculate. When necessary, activate it with the match_second_derivatives keyword, which is optionally followed by a boolean switch value. Note that the other improvement that Perlin mentioned in his paper has not been implemented.

1.2.4 Noise Generator Functions

Due to the large number of features the noise generator now has, the f_noise3d(x,y,z) function no longer suffices for noise in functions. To make up for this, Slime-POV allows you to declare noise generator functions:

NOISE_GENERATOR_FUNCTION:
	function {
		NOISE_GENERATOR
	}

These are used just like any other function. For instance:

	#declare my_favorite_noise_generator = noise_generator {
		3
		match_second_derivatives on
	}
	#declare my_favorite_noise_function = function {
		noise_generator {
			my_favorite_noise_generator
		}
	}
	sphere {
		0,1
		pigment {
			function {my_favorite_noise_function(x,y,z)}
		}
	}

Type 4 (four dimensional) noise functions take four arguments: one for each dimension (For instance, my_4D_noise_function(x,y,z,w)). The fourth argument overrides the slice parameter.

1.3 Smooth Triangle Normal Flipping Bugfix

As described in section 9.9 of the official POV-Ray 3.5 documentation, smooth triangles, smooth meshes, and smooth height fields sometimes show artifacts when they face away from the camera. This bug has been fixed.

1.4 Height Field Improvements

1.4.1 Normal Interpolation Bugfix

Anyone who has used a smooth height field to simulate terrain with some flat spots knows about the artifacts that can appear around the flat areas. These artifacts have been removed in Slime-POV.

1.4.2 Smoothing Types

In addition to the interpolation bugfix, there is also a new type of height field smoothing, that calculates the normals at each point with a different method. The smoothing method can be set with an integer after the smooth keyword as follows:

	smooth 0 | 1 | 2

Zero is no smoothing. One is POV-Ray 3.5's smoothing method. Two is the new smoothing method, which can create more pleasant results. Sometimes the difference is unnoticeable.

1.4.3 Smart Triangulation

All of the "squares" that a height field is made up of are created by two triangles. The division between these triangles, by default, is always diagonally from the upper left of the square to the lower right of the square. By adding the smart_triangulation keyword to a height field, you cause the height field to choose the division line in a way that creates the smoothest result. This causes the height field to take up a little more memory, but the effect is much nicer in some situations.

1.5 Shadow Line Artifact Fix

As described in section 9.8 of the official POV-Ray 3.5 documentation, sometimes smooth meshes or CSG objects with normal patterns display a sharp shadow line where one is not expected. This is caused by the object casting a shadow on itself from the inside. For further explanation, read section 9.8 of the official POV-Ray 3.5 documentation.

Slime-POV implements a fix similar to that proposed in section 9.8.4 of the official POV-Ray 3.5 documentation. When a point's true normal points away from the light source, but its perturbed normal points towards the light source, Slime-POV checks if the object self-shadows itself. If so, and if a few other minor conditions are met, every shadow ray intersection between the point in question and the shadowing point are ignored. To turn on the fix for a problematic object or mesh, add the fix_shadow_line keyword to the object.

Sometimes, however, in the case of a concave object, this can cause more artifacts. This happens when a point on the object is shadowed by itself and should be shadowed by itself. To prevent this, add a float constant after the fix_shadow_line keyword:

	fix_shadow_line MAX_DISTANCE

This float specifies the maximum distance between a point on the object and the point that shadows it. If the shadowing point is more than MAX_DISTANCE units away from the questionable point, then the shadow line fix will not be implemented for that point.

Note that if you scale or otherwise transform the object after specifying MAX_DISTANCE, the MAX_DISTANCE value will not scale with the object. The reasons for this are complex.

Note that the fix is nothing more than a workaround and cannot work perfectly in all situations.

1.6 Normal Accuracy Bugfix

This patch also includes a bugfix where specifying the accuracy of a normal through the accuracy keyword had no effect in some situations. This bugfix is enabled by default, provided you include the unofficial #version directive described in section 1.1.

1.7 A Final Note

If you find a bug in this patch, please:

  1. Create a minimal scene which demonstrates the bug.
  2. Test if the same bug appears in the official version of POV-Ray.

If it does, then please don't mention it to me. You may choose to report it to the POV-Team. If, however, the bug does not appear in the official version of POV-Ray, then feel free to send me the bug report. My contact information is available at slimeland.com. I may or may not choose to fix it. If the bug does not appear in the official version of POV-Ray, do not contact the POV-Team or povray.org about it. The POV-Team is not responsible for problems in my patch.

Remember that usage of the patch and the source code is subject to the terms and conditions in povlegal.doc. In addition, any patch based off of Slime-POV must retain my name in the credits.

Finally, remember that none of these features or bug fixes will work without the unofficial #version directive in your scene.

Oh, yeah, and have fun. Let me know if you do anything cool with it. =)