This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.

Your post and Alain's comments got me to thinking about this long-standingproblem, so I did some experiments (and a few animations). Here's what I've comeup with (in v3.6.1) using your code unchanged:

1) The cubic_spline type is *by far* the worst offender. It produces thosehyperbolas *outside* the object, plus the vertical 'plane' that Alain mentioned.It also takes MUCH longer to render than either a b_spline or linear_spline(about 10X longer!). The ENTIRE scene renders slower–every pixel. Moving thecamera way back–so that the sphere_sweep is barely visible in thescene–doesn't change this; in fact, the scene renders even *slower*, which iscompletely counter-intuitive. Changing the tolerance value doesn't affect it.Putting all of this together, it *seems* as though there's a 'visible' part ofthe object (the one we see) and an infinitely large INVISIBLE part as well, thatPOV-Ray is also having to do render calculations on –the outside artifactsshowing up as vestiges of this part. BTW, my animation tests seem to show thatthe 'plane' artifact is at the location of the asymptote of the hyperbolas (orone of them, anyway.) Not sure about that, though. And I still can't tell whythis 'plane' is showing up where it does; it has nothing to do with thesphere_sweep being made near POV's <0,0,0> origin location. (See 3) below.)

2) The b_spline and linear spline don't produce any artifacts *outside* theobject, except for that 'plane'–and it's actually more pronounced with alinear_spline than either of the other two spline types.

3) Creating the sphere_sweep somewhere other than near the origin (via itsspline points OR by translating it afterward)–and moving the cameralikewise–doesn't alter the artifacts. Changing the tolerance helps somewhat,but not with the cubic_spline's hyperbolas.

4) The artifacts don't seem to change their positions relative to the object,when the camera moves around. (I thought at first it was some kind ofcamera/sphere_sweep 'interaction'; but moving the camera via animation doesn'treally alter their behavior or location, it just shows them in 3-D space.)

My own conclusion is that the cubic_spline code (at least when used in asphere_sweep) needs to be re-worked. That may not fix ALL of the sphere_sweepartifacts, but would surely help!

Question (a bit off-topic): Is POV's b_spline the same as a natural_spline?Looking them up on Wikipeadia doesn't give me a clear answer.

A note about this issue: It is an ancient bug with the spline interpolation bounding computations not working. It has been known ever since sphere_sweeps where added to POV-Ray (as the bug existed in the original source). It was even discussed back then (3.5 beta), but nobody ever volunteered to implement the somewhat complicated mathematical solution to computing the correct bounding for spline based sweeps. The issue is that the code guesses the bounding for splines rather than computing it. The guessing fails for splines with "more extreme" splines where the sweep simply ends up being outside the bounding volume, causing plenty of artifacts due to intersections not being computed.

I don't think that's correct. It explains the slowness, but not the halos.

If it were MERELY a bounding problem, then either the bounding object would "clip" the object (if it was too "small" in places) or it wouldn't make any difference at all (if it was too large everywhere). Likewise, the problem would go away completely if you turned bounding off (since it would be very very slow, but still only draw things that belonged there).

This is a case where rays which SHOULD miss the object altogether are colliding with it, so it's a problem with more than just the bounding object.

Ok, as mentioned it's clear that there are two issues - the bounding and the artifacts.

For reasons mentioned above, fixing the bounding properly is difficult, so in the near term we need to consider what means could be used to work around this for the average user (i.e. someone not aware of the issue). For those in the know, it is possible to use bounded_by to manually specify the bounds.

The question then becomes, can we detect (or infer) the cases in which the bounding is behaving badly (either by being too small or too large). If we can it might have to be at run-time. If so, what do we do about it? Issue a warning that points to the docs discussing this?

The other option (less likely to happen) is to code a correct solution; if someone can correctly describe the maths needed then I would at least take a stab at coding it.

As to the artifacts, I'll have a look at that to see if I can locate the cause.

The disc artifact apparently has the same root cause as the artifacts described in FS#92 (fixing that error by modifying the square root solver will also make the disc in this cubic_spline issue go away). The other artifacts still remain unsolved, but I wouldn't be surprised if the underlying problem was similar (small polynomial coefficients, and a failure of the root solver or calling code to somehow normalize the polynom before trying to short-cut some computations).

While it must be conceded that we do have artifacts with the cubic_spline, this particular case is probably not a suitable example: The extreme choice of the first and last control point coordinates makes it a pathological case anyway, even if the algorithms were perfect. The long X coordinate distance causes a massive overshoot into the next interval, "telescoping" the sphere_sweep into itself, making it hard to tell which effects are due to this "telescoping" and which are real bugs in the sphere sweep code.

The following scene shows artifacts that are unrelated to such "telescoping":

From what I could find out so far, the primary reason for these artifacts is that the code does not directly try to solve for intersection points, but rather the location on the spline itself that corresponds to these intersections. This leads to problems when the front and back intersection correspond to (almost) the same location on the spline, in which case the respective intersection points cannot be unambiguously computed from the location on the spline, and will "flip" due to precision issues.

Chris, I think we'll need to come up with different math for the cubic spline sweep.

Does that mean my artifacts will remain (with no workaround) until the date of the cubic spline change? I'd like to use POVRay for this project, but if this is a "wait for the next revision" kind of fix, then I'll probably need to change that plan.

Does that mean my artifacts will remain (with no workaround) until the date of the cubic spline change?

I can't comment on whether or not there's no workaround (since for all I know someone might come up with another way for you to achieve what you need), but insofar as the existing code is concerned, there's really no straightforward way of fixing it: the issue is fundamental to the maths involved; i.e. it's not really a coding bug (insofar as we can tell).

I'll try to drop Jochen Lippert (the author of the original sphere sweep code) a line and see if he's interested in taking a look at it.

Does that mean my artifacts will remain (with no workaround) until the date of the cubic spline change? I'd like to use POVRay for this project, but if this is a "wait for the next revision" kind of fix, then I'll probably need to change that plan.

The disk artifact will be fixed in the next 3.7 beta (as a beneficial side effect of the fix for FS#92); if you need a fix earlier or can't use the betas, you will have to create and patch a custom version of POV-Ray, changing "polysolv.cpp" as follows: Locate the function "solve_quadratic"; in there, locate the statement reading "d = b * b - 4.0 * a * c;" (after the first if-block); before that line, place the following instructions: "b /= a; c /= a; a = 1.0;" (The function hasn't changed from 3.6 tp 3.7.) The function should now read:

As for the other artifacts, there is also a fix that reduces them considerably, though it will not eliminate them completely, nor do I know how it will affect performance: In file "sphsweep.cpp", locate the function "Intersect_Sphere_Sweep_Segment" (or "SphereSweep::Intersect_Segment" if you're patching a current 3.7 beta); in there, locate the second "switch" statement, subsection "case 4:". In there, you will find an "if(fabs(fp1) > ZERO_TOLERANCE) { ... } else { ... }" statement. replace the condition with "false"; your code should now look something like this:

Note that neither did I test these patches with 3.6, nor do I know how the second patch affects rendering speed (it will not solve the drastic bounding-box related slowdown; you will have to use custom bounding for that). However, it should get you somewhere in case you can't wait for an official fixed release or beta.

@Chris: In case the general overhaul of the cubic_spline sweep should take a while, we might try that second workaround as well for 3.7 betas. I think it's better than nothing, even despite leaving some residual artifacts and possibly being slower.

See attached file (_test.png) for a rendering with both patches applied (to POV-Ray 3.7 beta.36 in this case). Note that both disk and parabola are eliminated, and the artifacts on the right end cap as well; a thin line between left end cap and the sweep remains as a residual artifact though.