Applying procedural textures
General remarks
Compared to the physical material modelling with help of the brtd-functions, texture generation
can be seen as "artistic" material modelling. And like in the former case, a certain
amount of complexity is necessary for a satisfying result.
Consider the following
example: the well known starting point of all procedural textures are functions which are defined
throughout the space, returning a value between 0 and 1 (or -1 and 1) dependent of x, y and z,
which is used as a color-table entry to determine the color for this point. So the pattern is
everywhere, but becomes visible only at the surfaces of the objects, which appear as being
carved out of the material. Now, as one easily sees, no real furniture object is
produced in this way, so this simple approach alone most often fails to produce an acceptable
impression.
The functions still can be used for texture generation, but one has to consider carefully
where to evaluate them and accordingly transform/rotate their output to the place and
orientation where it is needed in the scene. If normal perturbations are involved,
this is even more necessary. Furthermore, the complex visual appearance
of common exterior/interior building materials demands modelling algorithms of adequate
complexity, which directly results in a lot of parameters.
The usual lack of time prevents me from a more detailed explanation of the set of cal-files
which produce various patterns. Each file contains a header section in which the function
arguments are named, this, together with the examples, should enable the interested ones
to understand what's going on and to adjust and create their own patterns with it and/or
write new cal files themselves. In the cal files, occasionally, some arguments are not used,
they proved obsolete during development. Nevertheless, dummy values have to be given as the
func-primitives otherwise would get out of step in counting and reading the arguments.(By keeping
them in the list, I avoided rewriting the file resp. the argument-numbering.) Many patterns offer
the possibility for tiling, as this reflects the way material is used in real buildings. If
tiling is not wanted, the files can nevertheless be used by setting the tiling dimensions greater
than the object size and transform the pattern such that the origin is not covered by the object.
(For circular mapping, some files are additionally provided in a version with axial tiling only,
as tangential translations would conflict with the mapping process).
To some extend, the textures are some sort of 'luxury'. Multiple layers with correspondingly multiple
calls to the noise-functions can be time consuming, but with help of the secondary ambient material,
the calculation time can be kept within practical bounds. Complexity of the assemblies is a matter, too,
as different names have to be given for the same pattern when it is used in several
rotated and transformed versions, meaning
that all the different components have to be named accordingly.
Of course one can think of reorganizing the texfunc/colorfunc primitives, but on the other hand, the
complexity of the matter itself somehow will show up in the end, either this way or otherwise.
Mapping
Because of the explanation mentioned above, mapping is often necessary for procedural textures
as well. Two ways are provided, circular and hermite mapping. The common thinking
behind it is, that a texture/pattern generating algorithm is evaluated in the xy or xz-plane
and the result is then applied on the object like a wallpaper. The cal files prepared for mapping are
recognizable by their names. Currently, the procedure is a bit awkward, since the RADIANCE
function primitives (colorfunc, texfunc, ...) can read in only one cal file, so mapping
and texture generation cannot be separated.
The circular mapping is straightforward, the texture is created in a plane parallel to the xy
(xz) plane and then wrapped around a cylinder with axis parallel to the y (z) axis.
The center coordinates of the cylinder x,z (x,y) , the radius and the z (y) value for texture
evaluation can be specified. (in general, the last one can be set to zero, meaning the
function is evaluated directly in the xy (xz) plane).
The hermite mapping is somewhat more complicated, as an additional mapping table has to
be calculated for it. (By providing a separate version of the function primitive, this
mapping table calculation could in principle be automically performed when the first ray hit
occurs, but this of course needs more programming effort.)
As an example, consider a hermite sweep produced with
the following gensurf command:
!gensurf mat name 'hermite(0,6,2.3,-1.5,s)' '2*t' 'hermite(0,0,4.0,6.5,s)' 10 1
For mapping a texture on this, call the utility program 'genmaptab' with the hermite
parameters as arguments plus the number of divisions for the table data:
$> genmaptab 0 6 2.3 -1.5 0 0 4.0 6.5 10
The number of divisions should be chosen between 6 and 20, higher values ensure greater
accuracy in mapping. 20 is the maximum (to limit the number of arguments handed
over to the cal file). It is independent of the parameter in the gensurf command
and does not need to be the same value.
'genmaptab -h' will put out a little help text. As a root solving process is
performed, you may be asked to raise an internal factor with the option -f.
The first hermite will always be taken as the 'independent' one, giving
the direction in which the sweep mainly evolves. As the textures basically
are defined either in the xy or the xz-plane, corresponding xy/xz-hermites
are possible, where x will always be the 'main direction'. The first position
value in the secondary hermite becomes the z (y) evaluation value for the textures.
To keep complexity at a minimum, it is advisable to start the first hermite
always at 0 and let the secondary start and end positions at 0, too, meaning
combinations of the form hermite(0, Px, R0a, R1a, t) and hermite(0, 0, R0b, R1b, t).
This is no loss of generality, as the object can be rotated and transformed to
the desired position separately.
Copy and paste the output of genmaptab to the end of the function primitive definition for
the chosen mapping-cal-file and finally raise the number of total arguments by the number
given in the output of genmaptab.
For complicated textures
it is most advisable to put them together with the object in a separate file
and place this into the scene with xform. This ensures that the texture is
automatically transformed to its proper place.