Christoph Lipka

For the records: I'll file this as "long-standing issue that we haven't found a simple solution to yet, so we sure don't want to tackle it in a hurry while...

Looks like the OpenEXR library proper has finally been renamed from `libIlmImf` to `libOpenEXR`. So all we'll have to do is update the `unix/config/ax_check_openexr.m4` automake script, and we should be...

Well, with _that_ out of the way, we're running into th next snag, namely that what had once been the IlmBase component of OpenEXR has been moved out into a...

... and plenty more cans of worms. I'm tabling this thing for now. We clearly have a problem with OpenEXR 3.0.

Addressed for v3.7.0 with pull request #422. _Addendum: In v3.7.0, using OpenEXR 3 may require specifying `CXXFLAGS="-std=c++11"` when running the `configure` script. We may or may not change this behavior...

Addressed for v3.8.0 with pull request #423. Will be addressed for v4.0 by (effectively or actually) merging the v3.8.0 branch at some later point in time.

@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?

Some questions/observations that make me doubt whether the change was made based on the whole picture, rather than just patching up symptoms: - Does it make sense to set `MIN_ISECT_DEPTH`...

> - 0.0 but the check is >, no more >= , and the test must remains to eliminate negative distance While that sounds plausible at a superficial glance, looking...

> The problem is this case is numerical and happens when the coordinates for the ray origin (often from a previous intersection) and in theory on the surface do not...