Port of FS226 - Near-coincident surface accuracy. Less accuracy in 3.7.

[wfpokorny]

http://bugs.povray.org/task/226

---

Details:

This is a transparent box very close to a plane.

box {
    -1, 1
    pigment { rgbf <0, 0, 1, 1> }
}

plane {
    #if (version < 3.7)
        y, -1.0000007
    #else
        y, -1.00007
    #end
    pigment { rgb 1 }
    finish { ambient 1 }
}

camera {
    location <1, 2, 3>
    look_at 0
}

The box is placed 100 times closer to the plane for 3.6, but both 3.6 and 3.7 produce exactly the same black artifact (attached).

So apparently 3.7 is less accurate. (And the exact factor 100 feels suspicious.)

near.png (1.9 KiB)

---

Comments:

---

Comment by Grimbert Jérôme (Le_Forgeron) - Monday, 10 September 2012, 00:04 GMT+5

Historical search (ignore case needed)

• Max_distance

    3.1g : 1.0e7
    3.6.1 : 1.0e7
    3.7RC5 : 1.0e7
    3.7RC6 : 1.0e7

• Small_tolerance

    3.1g : 0.001
    3.6.1 : 0.001
    3.7RC5 : 0.001
    3.7RC6 : 0.001

From comment in objects.cpp, a change occurred for >= MIN_ISECT_DEPTH
(no such limit in 3.6.1), or some postcondition in FindIntersection

For instance: in trace.cpp, the postcondition is := dist > SMALL_TOLERANCE

The post condition somehow contradict the comment about MIN_ISECT_DEPTH

I will try to experiment with the post condition later.

---

Comment by Grimbert Jérôme (Le_Forgeron) - Monday, 10 September 2012, 00:25 GMT+5

Post condition is not relevant for the original test scene.

But MIN_ISECT_DEPTH is !
at 1.0e-4 and 1.0.e-5, it's the picture of 3.7RC...
at 1.0e-6, back to the picture of 3.6

The comment (of objects.cpp) seems to ask for a less rough value than SMALL_TOLERANCE as MIN_ISECT_DEPTH, yet 1.0e-4 seems not small enough (compared to 1.0e-3 of SMALL_TOLERANCE).

See attached zip file:
FS226.zip

[wfpokorny]

I suspect this issue might be tangled with GH#121 & FS#324.

[c-lipka]

@wfpokorny I know you've done a lot of work in this area; can you give a brief status update pertaining to this particular issue?

[wfpokorny]

See my response in the pull #358 thread.

Quickly. Do nothing for v3.8. Merge Jerome's pull #358 (or implement similar) for v4.0 and sort issues including this one from there. I think his reversion of v3.7 change will likely, substantially help this one.

---

At the core of POV-Ray there are hundreds of numerical issues/limitations of which I've sorted hundreds in the povr branch (likely a few incorrectly...) - still many more to go. I don't really know how to now get more of those changes into POV-Ray proper. All complicated because often my work for any given change is now many years in the past...

Randomly, regarding SMALL_TOLERANCE and MIN_ISECT_DEPTH, both have been eliminated in povr as it stands today. There is another similar in SHADOW_TOLERANCE long hard coded at 0.001 - the same as traditional SMALL_TOLERANCE. It too has also been eliminated in the povr branch which now has a new shadow_tolerance keyword in the global_settings block. A setting which can often be adjusted to eliminate shadow 'see through due near intersection' artifacts.