There are many definitions of "fractal". By some definitions, only some of the images on these pages count as "fractal". For example, if a "fractal" is defined as an object with a non-integer Hausdorff-Besicovitch dimension, then the "Cantor Set" fractal here would count as a fractal, but the "Complement of the Cantor Set" fractal wouldn't. The mountain would count as a fractal, but the tree wouldn't.
Another definition is a non-integer box-counting dimension. By that definition, everything here counts as a fractal, if you first replace every primitive shape, such as a sphere or cylinder, with a point.
Barnsley, in Fractals Everywhere, defines a fractal to be any set, and then says that intuitively some sets ought to be called fractals, and some shouldn't. But he gives no definition for distinguishing them.
I call all of these objects fractals, since they have infinite numbers of components, appear qualitatively the same at many different scales, and correspond to an intuitive notion of "fractalness".
Each object is made up of a finite number of components. Each component is either a VRML primitive (e.g. a sphere or triangle), or is another fractal, possibly distorted. So, for example, the tree is made up of a single cylinder, for the trunk, plus two half-size trees for the two branches. Each half-size tree is identical to the whole tree, except it is compressed to half the size, and is rotated around. The mountain is simpler: it is made up of four copies of itself, and nothing else. Each copy is shrunk and distorted with an affine transformation. Some objects are actually made up of several fractals, each of which is in turn made up of small copies of each other.
An IFS is a type of fractal defined and analyzed by Barnsley. When a fractal here is made up only of other fractals, as with the mountain, then it is an IFS. If it also has ordinary objects added in, such as for the tree, then it is not an IFS. So the entire tree is not an IFS, but the set of leaves on the tree are.
No program can literally draw an infinite number of objects on the screen. There are two ways that we can get around this problem in VRML. One way is to represent a fractal with an approximation. For example, a fractal mountain might have only a million surfaces rather than an infinite number. From a distance, it would look similar to the true fractal, but up close you would notice that it was actually made from small, flat triangles. I call this approach a "pseudofractal", and find that it renders fast, and can be represented in a very small file.
A second approach is to have the object show only a few components at a distance, but then to automatically change and add more components as you get closer. VRML currently allows this with the LOD node. This can be slower in some cases, since the machine must constantly recalculate distances. But it can also be faster in some cases. For example, in a forest of fractal trees, only the nearest trees would be rendered in detail, and the distant trees would just be tiny green blobs. True fractals always generate smaller files than large pseudofractals, but the difference is small, and the pseudofractal might even take up less RAM while it's being rendered.
There is one major problem with true fractals, though. They are great for fractals like the tree, where the small trees are simply scaled-down versions of the large tree. But for fractals like the mountain, the components are squished in some directions, but actually grow in other directions. So a true-fractal mountain may not render well when you fly over it, even if it works well when you approach it from the side. This problem doesn't happen with the old LevelOfDetail command that used to be part of VRML. Unfortunately, when LOD was added, LevelOfDetail was removed, so there's no way to fix this.
One additional function in the code is very useful: VRMLtransform(). If you give it the (x,y,z) coordinates of 4 points in space, and the (x,y,z) coordinates that you want them to move to, then it will generate a single VRML Transform node that implements that affine transformation. It has lots of checks for special cases, and tries to make the output code as small as possible. This function was coathored by
Leemon Baird III and
L.C. Baird II.