Am 16.05.2017 um 13:43 schrieb William F Pokorny:
> On 05/15/2017 12:46 PM, clipka wrote:
>> Folks,
>>
>> I'm trying out a new approach at fixing the sphere sweep issues; please
>> give this version a thorough test:
>>
>> https://github.com/POV-Ray/povray/tree/experimental/sphere_sweep
>>
>> I'll build Windows binaries as soon as I find the time.
>>
> Absolutely a big improvement across my problem sphere_sweep problem
> collection - and more or less at speed.

I love to hear this.

Did you notice any new artifacts whatsoever?


> 1) We still sometimes get noise in the end result which I think AA will
> mostly clean up. The nosiest example is yours from Github #147:
> 
> https://github.com/POV-Ray/povray/issues/147
> 
> see the attached: LipkaFS81_Apr2010_Example.png image.

Note that this example, too, is a "planar" sphere_sweep, with all center
points on a plane perpendicular to the camera direction. I'd suspect a
connection there.


> 2) There is still too the ill formed polynomial into the solver planar
> when the segment coordinates are planar and the ray is perpendicular to
> the plane. See: Qfyd_Pete00_Jan19_2005.png where the scene is set up
> with an orthographic camera and the b_spline is in a plane perpendicular
> to all camera rays.
> 
> For such situations I was playing with the idea of checking for this
> special ill formed polynomial case; finding the ray intersection with th
> plane; testing if the point was this->Inside the sphere_sweep (the
> inside root solver test appears to be pretty stable result wise); then
> doing some magic with perturbed inside points I'd not sorted out... Code
> I have isn't too long so I'll include it too as an attachment with the
> thought you can probably get to a solution this faster than I can.

I must confess I can't yet claim to understand what you (or Massimo
Valentini) are trying to say.


> 3) We are still exposed some to badly formed input splines. The original
> FS81/GH147 is somewhat this case. Thought about adding some sanity
> testing in the parser. Doing this generally is probably not possible,
> but perhaps something like control point spacing > some multiple of the
> max of the two radius values would make some sense. Is it worth it?

Don't. Splines with very close control points can still be perfectly
well-behaved, and people might even deliberately generate them to get a
very close smooth approximation of some other curve.

Post a reply to this message