William F Pokorny <ano### [at] anonymousorg> wrote:

>      <+1.5,+0.91> // C4
>
> and the shape breaks apart(a)(b). In the bottom row I changed that last
> control point to:
>
>     <+1.5,+0.901> // C4
>
> and the entire top segment drops out.

Looking at the code, I'd say that either it's the solver or the EPSILON value -
or both.  That's definitely a weird result, and you have an excellent sense for
employing good incidental test cases.
I'd say that this is the kind of thing where more extensive diagramming of the
actual control points and cubic spline would be helpful, and maybe have a grid
of sor {} objects with varying control points.

I have a bit of trouble putting all of the pieces in sor.cpp together to see how
all of the data flows in order to make the actual sor on-screen.  If you could
explain that briefly, that would be a huge help in my ongoing investigations and
debugging.

Do you see anywhere that the code would simply not render the surface?  Any way
to indicate to the user that it does such a thing?

> (b) In yuqk the parts of the sor there all look good. In v3.8 beta 2,
> the results for top segment are noisy; Likely solver differences.

In the source:
Where is "Number" defined?
Where is EPSILON defined?

Some things I've noticed and am confused by:

In void Sor::Compute_Sor(Vector2d *P, RenderStatistics& stats) [Line 960]

starting at line 1003, we have:
    for (i = 0; i < Number; i++)
    {
        if ((fabs(P[i+2][Y] - P[i][Y]) < EPSILON) ||
            (fabs(P[i+3][Y] - P[i+1][Y]) < EPSILON))
        {
            throw POV_EXCEPTION_STRING("Incorrect point in surface of
revolution.");
        }

which is the only check that throws that error, and because it uses fabs (),
that doesn't actually check for the control points doubling back on themselves,
it seems like that's a check to make sure the tangent doesn't have a slope of
zero.

Now, moving down to line 1078, we have:
        while (n--)
        {
            if ((r[n] >= y[0]) && (r[n] <= y[1]))
            {
                x[n] = sqrt(r[n] * (r[n] * (r[n] * A + B) + C) + D);
            }
        }

and I'm confused as to why r is getting compared to the y value and not the x
value.  It seems that the radius ought to be compared to the control point x
values - unless I'm missing something.

Also, as far as I'm aware, the Catmull-Rom spline doesn't have as well-defined a
control polygon as a Bezier spline does, and so I'm wondering if there needs to
be a better bounding estimate for the min and max values.

So something that's been bouncing around the ole' noggin but I haven't yet
articulated is:
If we interpolate a spline with entirely valid control points, but the
interpolated part winds up crossing the rotation axis - what happens?

Post a reply to this message