Peter Popov wrote:
> How about adaptive subdivision based on screen resolution and using
> bicubic interpolation?

I think that would do just dandy. I'm having a problem smoothing a
height field myself, and I think adaptive interpolation would be the
ideal solution. Too bad that's not already in there, because I can't
think of any way I could implement it in my scene, which desperately
needs it.

Lummox JR

Post a reply to this message

Ron Parker wrote:
> On Mon, 07 Jun 1999 21:19:54 -0500, Bob wrote:
[snip]
> >The person originally wondering about "smoothing" a HF further would seem correct
then
> >about possibly interpolating via spline between the intitial triangle creation and
> >producing a further tessalation.

That person was me, incidently. I have a post in povray.bugreports
(didn't know a the time where else to post), and Bob and I have further
conversed about it in povray.general.
My problem is that I'm using a large-scaled height field to simulate
sand dunes, and the camera is down within the height field itself. This
proximity apparently aggravates a nasty problem with the surface normals
of the triangles, causing some to shine out brightly because they face
the light; they look like marching diagonals of checkerboard squares.
Smoothing only blurs them; it doesn't eliminate them, as it should.

> An interesting idea would be to implement a heightfield as a mesh of bicubic
> patches.  It'd be a memory hog, but it would probably look very good.

I had proposed a more aggressive smoothing algorithm which would do the
job for me--simply making the triangles look even less flat, causing
more bending toward the outer normals. But even better, I like Peter
Popov's idea of adaptively sampling the height field and
interpolating--indeed, I suggested something similar myself in the
thread on povray.general (Not-so-smooth height field).
Although I've considered changing to something like bicubic patches, the
problems in that are many. The height values would have to be
individually calculated from the existing height field data (how, I have
no idea) and thrown into the scene file as text; for a 1200x1200 height
field (which, granted, I could probably scale down considerably if I
used bicubics), that's a bit excessive.
It seems to me that some sort of automatic interpolation function--only
used when called for, of course, to speed rendering time--would greatly
improve the quality of height fields without requiring that kind of
effort. Or, even something as simple as more smoothing would do the
trick, at least in my case.

Lummox JR

Post a reply to this message

On Wed, 09 Jun 1999 20:05:18 -0400, Lummox JR wrote:
>It seems to me that some sort of automatic interpolation function--only
>used when called for, of course, to speed rendering time--would greatly
>improve the quality of height fields without requiring that kind of
>effort. 

Depending on what sort of "automatic interpolation function" you're 
planning on, you might as well use the bicubic patches.  They're the
end result you'd get with a bicubic interpolation, for example.
Adaptive interpolation would certainly be nice, but if you're going
to implement it, do it for all bicubic patches.

>Or, even something as simple as more smoothing would do the
>trick, at least in my case.

I don't think there's such a thing as "more smoothing."  It's either 
smooth or it isn't - the 'smooth' version doesn't actually displace
any points; it just mucks with the normal vectors to make it look
smoother.

Post a reply to this message

Ron Parker wrote:
> Depending on what sort of "automatic interpolation function" you're
> planning on, you might as well use the bicubic patches.  They're the
> end result you'd get with a bicubic interpolation, for example.
> Adaptive interpolation would certainly be nice, but if you're going
> to implement it, do it for all bicubic patches.

Well, I've never mucked around with the source code anyway, so that's
sort of out.

> >Or, even something as simple as more smoothing would do the
> >trick, at least in my case.
> 
> I don't think there's such a thing as "more smoothing."  It's either
> smooth or it isn't - the 'smooth' version doesn't actually displace
> any points; it just mucks with the normal vectors to make it look
> smoother.

Ah, but that's just what I mean: Those normal vectors can be displaced
even further, or less far, depending on the smoothness desired by the
user. There has to be a function which tells the smoothing algorithm how
much of one corner to use, how much of another corner, etc., and how
much of the plane normal. The way I see it, the big problem with my
scene is that the triangles don't use the edge/corner normal vectors
nearly enough, and instead use too much of the plane normal. Thus, the
triangles still have a somewhat "flat" appearance, except at their very
edges, when instead they should look flat only very close to the middle.
An altered "smooth" keyword would be key, here, so "smooth 1.0" could be
the default smooth function, whereas "smooth 5.0" would tend to perturb
the normals more in favor of the corners.

Lummox JR

Post a reply to this message

On Fri, 11 Jun 1999 16:19:18 -0400, Lummox JR wrote:
>Ron Parker wrote:
>> I don't think there's such a thing as "more smoothing."  It's either
>> smooth or it isn't - the 'smooth' version doesn't actually displace
>> any points; it just mucks with the normal vectors to make it look
>> smoother.
>
>Ah, but that's just what I mean: Those normal vectors can be displaced
>even further, or less far, depending on the smoothness desired by the
>user. There has to be a function which tells the smoothing algorithm how
>much of one corner to use, how much of another corner, etc., and how
>much of the plane normal. 

Sorry, no, that's not what it does.  It calculates the normal at each
corner, then linearly interpolates between corners.  There is no 
"plane normal."  The normal vector varies continuously across the 
surface of the object.  Whatever you're seeing, it's not due to 
normals.

Post a reply to this message

Ron Parker wrote:
> Sorry, no, that's not what it does.  It calculates the normal at each
> corner, then linearly interpolates between corners.  There is no
> "plane normal."  The normal vector varies continuously across the
> surface of the object.  Whatever you're seeing, it's not due to
> normals.

Ah, I see. Of course, that's similar to what I thought it was doing
anyway.
At any rate, a "smooth <value>" keyword could be used to change from
linear interpolation to a non-linear value. It could be applied as an
exponent, for example, with 1.0 being the linear default. A higher
exponent would mean more smoothing.
For example, if the current routine interpolates between vectors based
on d and 1-d, the distance from each corner, then d^2 and (1-d)^2 would
tend to cause a lot more biasing toward the edges.
A simple interpolation (obviously not what the triangles use, but just
an example) might look like this:

(v1*d + v2*(1-d))/(d+(1-d))

If an exponent was added, it could be like this:

(v1*d^2 + v2*(1-d)^2)/(d^2+(1-d)^2)

Thus the weights in the average change in a non-linear fashion.

Lummox JR

Post a reply to this message

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

Wish I had spoken up earlier, this topic should really be carried out in the
povray.programming newsgroup. Building up quite a case for a change in the
'height_field' here and just isn't the right place to discuss it when there's a better
place.

Post a reply to this message

On Sun, 13 Jun 1999 23:58:46 -0400, Lummox JR wrote:
>Zero should produce a very flat surface--but interestingly, it will
>remove the two-triangle appearance caused by no smoothing at all.

This is true.  It's because the normal is interpolated (or in this
case, averaged) across the square, not across the two triangles.  
The triangles end up being rendered with a different normal than 
they actually have.  This is interesting code, but I'm not sure
whether 'smooth' is the right word for what it does.

Post a reply to this message

Ron Parker wrote:
> 
> On Sun, 13 Jun 1999 23:58:46 -0400, Lummox JR wrote:
> >Zero should produce a very flat surface--but interestingly, it will
> >remove the two-triangle appearance caused by no smoothing at all.
> 
> This is true.  It's because the normal is interpolated (or in this
> case, averaged) across the square, not across the two triangles.
> The triangles end up being rendered with a different normal than
> they actually have.  This is interesting code, but I'm not sure
> whether 'smooth' is the right word for what it does.

Well, I posted it in the povray.programming group as well, touting it as
a possible superpatch addition. Personally, I'd be thrilled if you
decided to throw it in there--it'd save me the work of trying to make
the necessary modifications myself, since I know very little about
working with the source code.

Lummox JR

Post a reply to this message