Artifacts on bezier lathe object.

[wfpokorny]

Summary

Artifacts appear near the center of the bezier lathe object sturm or not. With some severe rotations away from the camera result OK.

Originally reported in the newsgroups at:

http://news.povray.org/povray.bugreports/thread/%3Cweb.59dbe72e2e96ce0e146834bc0%40news.povray.org%3E/

and we suspect, but have not proved, the issue is similar to that still seen and documented in the sphere_sweep issue #147.

Environment

Demonstrated with all 3.8 versions from first in early July through current at v3.8.0-alpha.9322209 as well as a couple earlier 3.7.1 versions. Both windows and linux environments.

Steps to Reproduce

Ubuntu linux command 'povray vlathe.pov +D +P'

Render Settings

3.8.0 as shipped Defaults.

Scene

#version 3.8;
global_settings { assumed_gamma 1.0 }
camera {
  right x*(image_width/image_height)
  location <0, 0, -10>
  look_at <0, 0, 0>
  angle 35
}

light_source { <-5, 20, -10>, color rgb 1 }
light_source { <5, 20, -10>, color rgb 1 }

// Vuvuzela, with mouthpiece around <2, 0, 0>, flare around <-2, 0, 0>,
// and max diameter around 1.
#declare Vuvuzela = lathe {
//linear_spline
  bezier_spline
  24,
  // mouthpiece
  <0.001, 0.2>, <0.001, 0.2>, <0.06, 0.11>, <0.06, 0.1>,
  <0.06, 0.1>, <0.06, 0.09>, <0.07, 0.09>, <0.07, 0.1>,
  <0.07, 0.1>, <0.07, 0.15>, <0.05, 0.19>, <0.04, 0.2>,
  // rest of the vuvuzela
  <0.04, 0.2>, <0.04125, 0.6>, <0.1, 3.5>, <0.5, 3.9>,
  <0.5, 3.9>, <0.51, 3.91>, <0.51, 3.92>, <0.5, 3.92>,
  <0.5, 3.92>, <0.49, 3.92>, <0.1, 3.8>, <0.001, 3.8>
  sturm
//rotate 33*x    // OK if camera rays not near parallel to surface normal
  translate -2*y
}

object { Vuvuzela pigment { color rgb <1, 0, 0> } }

Workaround

If camera can be set up such that camera rays not 'axis-aligned' with surface's normal. High Anti-Alias settings 'can' help - if AA rays mostly less axis-aligned to the surface normal. Rendering larger image - perhaps using AA - and scaling the image down might help too.

Suggested Solution / Partial Solutions.

Likely some adjustment or fix to the polynomial solver - or a reformulation of the input polynomial - is needed for a full solution. See issue #147 plus links to newsgroup discussions from that issue for more.

Given we are working with a lathe, perhaps some cheat can be used that takes advantage of the constrained solution space.

Applying I think to both #147 and this issue, there is a performance related suggestion made by Simon to better initially bound the potential solution space for the solver buried within issue #236. I tested this idea while working with #147 and it both helped performance and accuracy. Not that I'm any expert, but many books on numerical solutions - "Numerical Recipes in C" for example - suggest polynomial solvers start with the best initial bounds for the expected solution as possible. We don't. Our solver always runs from camera origin to MAX_DISTANCE despite having bounding box information for the expected result(1). With this lathe example, when I hard code a max distance value of 10 in polysolve() the artifacts are not eliminated, but they are reduced(2).

(1) - Thinking an exact max distance from each ray->bbox is likely not an option performance wise, but perhaps a better estimate than MAX_DISTANCE passed into the solver is possible? Maybe something like a parse / bbox calculation time calculated maximum distance given all bboxes and the camera location?

(2) - This also hints - as when working on #147 - that our solver is capable of better solutions. Today the solver code has a couple accuracy controls combined and hard coded. Bringing these controls out through the SDL for 'problematic' solutions like the lathe example in sturm-ish kind of way might be an option too. As with sturm, there would be a performance cost for the better accuracy. We'd be left with the fundamental issue for rays almost exactly axis-aligned to the surface normal no matter - into fundamental solver work or reformulation of the input polynomial and work beyond my capabilities at present.

[c-lipka]

Is this a regression from v3.7.0?

[wfpokorny]

Not sure what you mean by your question?

I ran 3.7.0 and 3.6.1 just now and the same artifacts appear - supposing you were asking whether this example has issues in older releases.

[wfpokorny]

FYI. I now have a branch which fixes this issue at:

https://github.com/wfpokorny/povray/tree/fix/polynomialsolverAccuracy

I have still to run down some unrelated solver accuracy issues so I'm not creating a pull request as yet.