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

Am 02.05.2016 um 18:37 schrieb Bald Eagle:
> I have always wondered what the big deal about negative values was, since once
> it gets revolved 180 degrees, it's the positive value.
> 
> Can the on-curve points simply be redefined to be positive?
> on_curve[n] = abs(original_curve[n]) ?
> 
> I could of course, be way off base with this.

And indeed you are, as LanuHum correctly points out ;)

Because this shape...:

    A
  + |\  /|
  __| \/ |_____axis
    | /\ |
  - |/  \|
         B

... is obviously completely different from this one:

    A____B
  + |    |
  __|    |_____axis
    |    |
  - |____|

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 02.05.2016 um 18:37 schrieb Bald Eagle:
> > I have always wondered what the big deal about negative values was, since once
> > it gets revolved 180 degrees, it's the positive value.
> >
> > Can the on-curve points simply be redefined to be positive?
> > on_curve[n] = abs(original_curve[n]) ?
> >
> > I could of course, be way off base with this.
>
> And indeed you are, as LanuHum correctly points out ;)
>
> Because this shape...:
>
>     A
>   + |\  /|
>   __| \/ |_____axis
>     | /\ |
>   - |/  \|
>          B
>
> ... is obviously completely different from this one:
>
>     A____B
>   + |    |
>   __|    |_____axis
>     |    |
>   - |____|

Oh, see - what I was thinking was that the WHOLE curve would be processed in
context, which would not lead to your second scenario, but to:

>     A    B
>   + |\  /|
>   __| \/ |_____axis

Which ought to give the same as your first scenario, no?

Post a reply to this message

Am 03.05.2016 um 02:34 schrieb Bald Eagle:

> Oh, see - what I was thinking was that the WHOLE curve would be processed in
> context, which would not lead to your second scenario, but to:
> 
>>     A    B
>>   + |\  /|
>>   __| \/ |_____axis
> 
> Which ought to give the same as your first scenario, no?

That may be what you were thinking, but it's not what happens. It's
simply not how POV-Ray works internally.

It's not like POV-Ray iterates over all the points on an object's
surface and shoves each into the image, so that it could just shuffle
around points arbitrarily in 3D space as it goes along.

What POV-Ray instead does is that it iterates over all the points in the
result image, computes the line in 3D space that is projected onto that
point in the image, and then essentially solves a mathematical equation
to figure out all the points at which that line intersects any given
object in the scene.

Now if POV-Ray finds a point on a lathe, it is too late to do any
rotation by 180 degrees -- because the resulting point will most likely
not be on the line anymore.

Post a reply to this message

On 05/02/2016 03:16 PM, clipka wrote:
> 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:
>
...
>

Thanks Christoph as always for the detailed thinking. I'll sleep on your 
questions and dig into specifics tomorrow morning.

Responding quickly for now, I kind of expected bounding to break and for 
surfaces to flip inside out with negative coordinates.

I cannot see a reason to, say, make right all shapes/bounding when 
passed negative on curve points because at the moment I believe we can 
otherwise create the same - intended - shapes with, all positive, on 
curve points.

Sturm was on.

Maybe too I'll take a quick look into why -MB isn't working in 3.7* as 
it would be nice to see these shapes rendered with bounding completely 
off.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 05/02/2016 03:16 PM, clipka wrote:
> > 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:
> >
> ...
> >
>
> Thanks Christoph as always for the detailed thinking. I'll sleep on your
> questions and dig into specifics tomorrow morning.
>
> Responding quickly for now, I kind of expected bounding to break and for
> surfaces to flip inside out with negative coordinates.
>
> I cannot see a reason to, say, make right all shapes/bounding when
> passed negative on curve points because at the moment I believe we can
> otherwise create the same - intended - shapes with, all positive, on
> curve points.
>
> Sturm was on.
>
> Maybe too I'll take a quick look into why -MB isn't working in 3.7* as
> it would be nice to see these shapes rendered with bounding completely
> off.
>
> Bill P.


Bold I selected. The control peak is in a negative, but it only brings closer
positive points of a curve to zero. It can't prevent Povray to calculate a
surface

Post a reply to this message

Attachments:
Download 'lathe.jpg' (43 KB)

Preview of image 'lathe.jpg'

clipka <ano### [at] anonymousorg> wrote:
> Am 03.05.2016 um 02:34 schrieb Bald Eagle:
>
> > Oh, see - what I was thinking was that the WHOLE curve would be processed in
> > context, which would not lead to your second scenario, but to:
> >
> >>     A    B
> >>   + |\  /|
> >>   __| \/ |_____axis
> >
> > Which ought to give the same as your first scenario, no?
>
> That may be what you were thinking, but it's not what happens. It's
> simply not how POV-Ray works internally.

I guess I was speaking about the initial "spline" that then gives rise to the
shape that is enclosed by its rotation about the axis.  If you first example
were caught by the parser, corrected to the above, and THEN the rest of
POV-Ray's internals were let loose on it....

I suppose I'll just bow out since I don't have the source code / flowchart in
front of me.  ;)

> It's not like POV-Ray iterates over all the points on an object's
> surface and shoves each into the image, so that it could just shuffle
> around points arbitrarily in 3D space as it goes along.
>
> What POV-Ray instead does is that it iterates over all the points in the
> result image, computes the line in 3D space that is projected onto that
> point in the image, and then essentially solves a mathematical equation
> to figure out all the points at which that line intersects any given
> object in the scene.
>
> Now if POV-Ray finds a point on a lathe, it is too late to do any
> rotation by 180 degrees -- because the resulting point will most likely
> not be on the line anymore.

Fully understood. I didn't imagine that's the way it worked.

Post a reply to this message

On 05/03/2016 01:40 AM, LanuHum wrote:
>
> Bold I selected. The control peak is in a negative, but it only brings closer
> positive points of a curve to zero. It can't prevent Povray to calculate a
> surface
>

My morning coffee is still brewing, but yes, I understand povray should 
handle your bezier curve where only one of the control points is 
negative in x.

I have captured the code you posted to github as another test. It 
renders OK in the copy of code where I turned off the current checking.

Thanks for checking I understood!

Bill P.

Post a reply to this message

Am 03.05.2016 um 13:17 schrieb Bald Eagle:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 03.05.2016 um 02:34 schrieb Bald Eagle:
>>
>>> Oh, see - what I was thinking was that the WHOLE curve would be processed in
>>> context, which would not lead to your second scenario, but to:
>>>
>>>>     A    B
>>>>   + |\  /|
>>>>   __| \/ |_____axis
>>>
>>> Which ought to give the same as your first scenario, no?
>>
>> That may be what you were thinking, but it's not what happens. It's
>> simply not how POV-Ray works internally.
> 
> I guess I was speaking about the initial "spline" that then gives rise to the
> shape that is enclosed by its rotation about the axis.  If you first example
> were caught by the parser, corrected to the above, and THEN the rest of
> POV-Ray's internals were let loose on it....

That would imply what I described to William as solution variant (C):
The parser would first have to...

- solve the spline equation in 2D space for intersections with the axis;

- add any such intersection points into the spline to split it up into
more segments:

    A    B
  + |\  /|
  __| \/ |_____axis
       P

- in case of quadratic, cubic or bezier splines, insert additional
control points in such a manner that the shape of the original curve
between the points is preserved.


Especially the last step is a non-trivial thing to do, and I guess it
may be easier to just fix the intersection computation to handle
"flipped" portions in the shape.

Post a reply to this message

Am 03.05.2016 um 14:22 schrieb William F Pokorny:

> I have captured the code you posted to github as another test. It
> renders OK in the copy of code where I turned off the current checking.

Does it also compute the surface orientation properly?

Post a reply to this message