On 03/30/2018 08:21 AM, William F Pokorny wrote:
> 
> Branch fixes this blob issue, the lathe issue #335 from last fall and 
> many remaining #147 (sphere_sweep) solver issues - except one b_spline / 
> orthogonal camera case. The patch also fixes or makes better many of the 
> accuracy issues I have in hand, however, I have too still some scenes 
> with 'accuracy' issues to dig through. The work is tedious and I need a 
> break - so putting out the fix I have.
> 
> A branch of master with the code update is available at:
> 
> https://github.com/wfpokorny/povray/tree/fix/polynomialsolverAccuracy
> 
> for those compiling their own POV-Ray versions. I plan to create a pull 
> request once I've looked at some of the remaining accuracy issues.
> 

I've run down another type of solver issues related to our sor object. 
In this case the problem is with the sor polynomial set up often not 
crossing through 0.0 which is a requirement for the sturm / polysolve 
methods.

The ray / sor set up sometimes creates sets of coefficients which are 
are all positive or negative which sturm / polysolve sees as meaning 
there are no roots to find. The fix is to perturb the direction vector 
by +EPSILON during the set up which is in my testing enough to get the 
crossing 0.0 criteria always.

I started with a sor scene shown in the top row of the attached image 
which Severi Salminen posted in 2004. v381 shown on the left and the fix 
on the right.

(The remaining three rows show differences at 4x the real magnitude.)

The second row is our shipped sor1 sample scene which doesn't use sturm 
at all. I expected no difference, but the 'sturm off', solve_cubic() 
function is also failing to find roots on reflected rays which I didn't 
previously notice. The +EPSILON change perturbs these noisy solution 
regions.

The third row is the same sor1 scene, but with sturm turned on for all 
sor objects meaning polysolve gets used. The difference on the right of 
row 3 shows how a noisy original solution is cleaned up with the fix.

The last row shows the updated code's solve_cubic solution vs the 'sturm 
on' / polysolve solution.  Note that 'sturm on' is needed for clean 
roots & a clean sor1.pov image.

Aside: Yes, it's looking like continued rays whether transmitted or 
reflected tend to be harder for the solvers to handle. This echoes back 
to early lemon issues with noise when the texture had a reflective 
component. Also true errors in continued rays are often harder to see 
given the contributions are mixed with any ambient or diffuse components.

I've more solver accuracy issues to run down, but I've updated the 
branch at:

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

with this sor polynomial set up fix for those interested.

Bill P.

Post a reply to this message

Attachments:
Download 'sorsoverstory.jpg' (317 KB)

Preview of image 'sorsoverstory.jpg'