Height Fields

Height fields are one of the most flexible geometric primitives in POV, and POV can easily handle height fields with several hundred points in each direction. For renderman the situation is a little bit complicated. The standard includes an optional feature to displace the points of a surface. This is basically meant to add small details to a surface but can be taken to the extreme to produce heightfield effects with a shader which displaces any point on a surface along the normal to the surface by an amount determined by the color of the corresponding point (supersampled and antialiased from the actual pixels) in the image used as a height field. This is far more flexible than POV's height field, because you are not limited to a square field, but can use the same shader on a sphere or NURBS or whatever to raise and lower points on its surface etc.

The other way is to emulate a height field with a little program that turns an image into a PatchMesh or into PointsPolygons. I found out that the most efficient version is a bilinear patch mesh with explicitly defined normals. It still uses more memory than POV and is considerably slower (even if rendered without shadows), but the result is better. Here are three pictures that use the same 128x128 image created by gforge as a height field. The first is a POV-height_field and uses the "smooth" option, the second is a bilinear patch mesh with explicitly set normal vectors at each vertex and the third image uses a displacement shader and a bilinear patch. The last two images have been rendered with BMRT.

Some numbers for my configuration (Linux 2.0.27, P90, 16MB RAM, POVRay 3.0, BMRT 2.3.5):

The original pgm-file has 88KB. The RIB-file with PointsPolygons generated from this had more than 14MB. The bilinear version has a 900KB RIB file. As a bicubic patch mesh the RIB-file is considerably smaller, but my virtual memory was exhausted before the image was done.