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 
gkMinIsectDepthReturned(1).

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.

Bill P.

Post a reply to this message