I have (finally) a more intelligent response regarding the smoothing
function.
In my last post I mentioned some pseudocode that would do what I was
suggesting for the textures. Now I finally have some *actual* code that
describes what I want to do with the height fields.
----------------------------------------------------------------------
This is an example of the height_field code in hfield.c, modified to
allow a more user-defined smoothing function. Although it won't produce
results as accurate as Peter Popov's adaptive-sampled bicubic idea,
because the surfaces are still flat, it should still allow the user to
increase or decrease the amount of smoothing. I took a look at the
superpatch source code, here, though I imagine exactly the same changes
would apply to the original POV-Ray 3.1 executable.

Naturally, changes are also required in parse.c to allow the smooth
keyword to accept a numeric value (or to use 1.0 as a default if the
keyword is found). The change would go something like this:

height_field {
    ...
    smooth [float value]
    }

The float value is smooth_exponent, a value used in the normal
calculation process. If this is just 1.0, then linear interpolation of
the corner vectors (the current default) is still used, and the
original code is called for the sake of speed. If it's not 1.0, the
exponent is applied and used to warp the u, v, x, and z values.

----------------------------------------------------------------------
Segment of original HField_Normal() code (for smoothed normals):

    x = stretch(x);
    z = stretch(z);

    u = (1.0 - x);
    v = (1.0 - z);

    Result[X] = v*(u*n[0][X] + x*n[1][X]) + z*(u*n[2][X] + x*n[3][X]);
    Result[Y] = v*(u*n[0][Y] + x*n[1][Y]) + z*(u*n[2][Y] + x*n[3][Y]);
    Result[Z] = v*(u*n[0][Z] + x*n[1][Z]) + z*(u*n[2][Z] + x*n[3][Z]);

Segment of proposed new code:

    x = stretch(x);
    z = stretch(z);

    u = (1.0 - x);
    v = (1.0 - z);

    /*
        smooth_exponent is a part of the height field structure itself,
        and div should be declared in the beginning of this function.
        Some error checking may be required when calling the pow()
        function, since it could cause numerical underflow or overflow.
     */

    if(smooth_exponent==1.0) {
        Result[X] = v*(u*n[0][X] + x*n[1][X]) + z*(u*n[2][X] +
x*n[3][X]);
        Result[Y] = v*(u*n[0][Y] + x*n[1][Y]) + z*(u*n[2][Y] +
x*n[3][Y]);
        Result[Z] = v*(u*n[0][Z] + x*n[1][Z]) + z*(u*n[2][Z] +
x*n[3][Z]);
        }
    else {
        x=pow(x,smooth_exponent);
        z=pow(z,smooth_exponent);
        u=pow(u,smooth_exponent);
        v=pow(v,smooth_exponent);
        div=(x+u)*(z+v);
        Result[X] = (v*(u*n[0][X] + x*n[1][X]) + z*(u*n[2][X] +
x*n[3][X]))/div;
        Result[Y] = (v*(u*n[0][Y] + x*n[1][Y]) + z*(u*n[2][Y] +
x*n[3][Y]))/div;
        Result[Z] = (v*(u*n[0][Z] + x*n[1][Z]) + z*(u*n[2][Z] +
x*n[3][Z]))/div;
        }

----------------------------------------------------------------------

A higher exponent causes the x and u values, and z and v, to diverge
farther from each other, thus biasing the result to favor the corners
more heavily. Since the normal will now be seen as if it was further
toward the edge, the triangle will have a much more rounded appearance.

Naturally, a lower exponent will have the opposite effect, converging
the values toward each other, and thus away from the corners. A low
smoothing value should cause a semi-faceted look, with smooth edges
but a flat center.

Zero should produce a very flat surface--but interestingly, it will
remove the two-triangle appearance caused by no smoothing at all.
Bizarre effects could come of using negative values, because the
normals for all the corners will be effectively swapped.


Lummox JR

Post a reply to this message