Am 02.05.2016 um 19:47 schrieb William F Pokorny:

> I think I covered all the cases somewhat, but if not let me know.

What about these:

- first and third point negative

- second and fourth point negative

- first and fourth point negative

Also, so far you've only swapped the signs; what if the negative values
have greater magnitude than the positive ones? What about quadratic
splines with an odd number of control points?

There's plenty more stuff to toy around with.

I also think it would be worthwhile to examine what happens if the lathe
has an interior_texture.


> To my eyes we get what one might expect(1) with negative coordinates, so
> running with better warnings or no checking at all of the points in the
> spline is probably OK.

I'm not happy at all with the following cases:

- the entire column 1 (all-negative); technically these should look the
same as column 0, shouldn't they?

- the cubic spline column 6; we should see /something/ there

- the quadratic spline columns 6 and 7; we do see from the shading that
they are bulging, but the silhouettes are cylindrical in the
orthographic view, and the shapes look cut off in the perspective view.

My suspicion is that the internal bounding mechanism of the late
primitive doesn't play nice with negative values, which would explain
all the above oddities.


Furthermore, columns 5 and 7 should look identical in all respects for
all splines, but instead we consistently see notable differences in the
shading (and maybe also self-shadowing, but that's not entirely clear).
This indicates to me that the normal computations are thrown off the
rails by negative values as well.


This means you(!) now have a choice to make:

(A) Just overhaul the error message check.

(B) Fix the lathe primitive itself, by making the bounding mechanism
properly deal with negative values (this should be reasonably easy) and
making the normal computations properly deal with "flipped" portions
(this might be more difficult).

(C) Work around the lathe primitive's limitations at the parser level,
by automatically splitting any non-conforming sections into two or three
sub-sections, inserting additional control points along the way, and
normalizing the "flipped" portions by just inverting the sign. (This
should be trivial for linear splines, some work for bezier splines, but
may turn out to be difficult or even impossible for quadratic and cubic
splines.)

(D) Just like (C), but make the corresponding code part of the lathe
primitive itself by placing it inside the Lathe::Compute_Lathe() method.


Any of the above solutions would be accepted (presuming the resulting
implementation is of reasonable quality of course).


One final note in case you go for (A): In addition to the error messages
for negative on-curve control points I'd also like to see warnings for
negative off-curve bezier control points, as such points may or may not
lead to "flipped" portions and the normal computation for such portions
demonstrably cannot be trusted at present. Of course it would also be
neat if the parser could automatically detect whether a lathe object
will actually have "flipped" portions (not only for bezier but also for
quadratic and cubic splines, which can "overshoot" even with
all-positive control points) but that's probably beyond the scope of
parse-time parameter sanity checks.


> (1)- except perhaps that quadratic is a bit noisy, but probably it is
> not much used.

Try "sturm", that should give smoother results.

Post a reply to this message