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