Issue was caused by changed function signature. This is still not really full
support of new OSL API since we don't store anything in the derivatives which
could confuse mipmapping.
Notes:
- There is still some bvh cache code, but that is from the engines initial commit, we might clean this up further or keep it.
- Changes in util_cache.h/.c are kept, this might be re-used in the future.
This removes the BVH cache feature from the UI, underlying code will be removed in a separate commit.
The BVH cache was added before we had a multi-threaded BVH build, and a lot of other optimizations were done since then, which makes this not useful anymore.
Fix T46162.
So now the following OSL versions are supported (at least for compilation):
- 1.5 with closure alignment patch applied
- 1.6.8 release
- 1.7 development version from latest git
Added some extra seed to the hash, so it's now less likely to give repetitive
patters at values around zero.
This will change distribution of bricks for existing files. but it's something
inevitable.
Epsilon was quite arbitrary for GPU, replaced with checking for zero-sized faces.
It should solve both original report and the new one. After the release we can check
why GPU doesn't produce accurate math here and go to the root of the issue.
Disable Intel cards for until we'll go to the root of the issue of the crash.
This will take a bit, so being so close to the release we go safe and disable
unstable GPU, so blender at least doesn't crash.
This could be bypassed by setting OPENSUBDIV_ALLOW_INTEL environment variable.
Found a way to make AVX2 CPUs happy by reshuffling instructions a bit,
so now there's no weird precision errors happening in there.
This solves some render speed regressions on CPU, but unfortunately
this doesn't help for GPU rendering.
It can't be simply removed in cases when it's connected to input which is
different from Normal. This is because the input wouldn't be connected to
default Normal geometry input, possibly breaking shading setup.
The fix is not really ideal, but should work at least.
This fixes skin having too much glossy reflection in the file from T46013.
Initial idea was to optimize calculation a bit by skipping calculation of actual
triangle edges and use vector from ray origin to triangles. In practice this
optimization didn't quite work in cases when origin point is too close to the
triangle.
Let's do 2.76 with a bit more complicated calculation, still looking into exact
reasons why watertight intersections fails in certain cases, but actual fix might
bit be ready so soon.
This fixes wrong eyes on the lady from T46013.
The issue was caused by wrong detection whether number of verticies
changed or not. Basically, it wasn't working correct in cases when
number of verticies is increasing compared to the current frame.
This isn't really complete fix, complete fix would require calculating
derivatives via OIIO API, but supporting this will either end up with
some code duplication or will require some non really safe changes at
this release cycle.
