On 8/15/20 12:35 PM, William F Pokorny wrote:
> On 8/15/20 11:21 AM, jr wrote:
> I see it too in all my recent povr versions. It was OK in versions early
> this year, so something I've done between then and early July.
> I'll do a binary search - compile/run through my commits to find the
> commit causing the problem. FYI. No photons required to see it.
I broke the checker pattern on March 29th. ;-)
There has been a defined EPSILON value floating around in the code for a
long time. Over the years it sort of got used any time folks had the
thought, "I need an epsilon value." All to often it was (at 1e-10) a
non-optimal value to use.
I've been cleaning these up; mostly breaking them into two buckets after
determining what I thought good values numerically while doing my solver
work. A treat this as zero epsilon and a good supportable intersection
depth tolerance. The former I called gkDBL_epsilon which is a little
larger than the C++ DBL_epsilon macro value and the other is called
When I updated EPSILON in the checker pattern, I used gkDBL_epsilon when
I should've used gkMinIsectDepthReturned. Yes, this is an intersection
with a plane, low order and more accurate - it was mostly working
anyway. The actual supportable value is certainly between the two values
I settled on. But, going with the standard gkMinIsectDepthReturned in
checker unless something 'else' breaks.
Aside: Yes, sometimes you really need somewhat unique 'epsilon' values.
When I was cleaning up the tiling patterns for isosurface use, I ran
across a collection of such values where someone had commented that a
C++ macro should perhaps be used. But in testing each, every one of
those needed to be what they were to the order of magnitude. Jerome had
done his homework! :-)
Anyway, thanks again for spotting this / testing.
Post a reply to this message