This reverts commit 12abe94de827d9ae9c0dd6cc49bc6c3e377842ad.
After a long discussion in the bug tracker we decided baking should use
the faces normals for glossy (and combined). This is what Blender
Internal is doing, and one of the more predictable way of yielding
predictable results.
That also means the result will not match the render perfectly, but this
is preferrable over the alternatives at hand.
Conflicts:
intern/cycles/kernel/kernel_bake.h
Comments from Brecht Van Lommel:
"""
Currently the viewing direction for each pixel is set to the normal, so
at every pixel glossy is evaluated as if you're looking straight at it.
Blender Internal works the same.
"""
This patch makes baking glossy as viewed from the camera.
Reviewers: brecht
CC: zanqdo
Differential Revision: https://developer.blender.org/D555
The kernel for baking the world texture was the same as the one used for
baking. Now that's separate which allows the kernel to reserve much less
memory.
CMake had this --fast-math flag but scons not, makes a big difference on some
files. Slightly slower rendering might still happen though, but it should not
be this much.
The remaining functions in blender_python.cpp changed from using the
MACRO to use python_thread_state_save/python_thread_state_restore
Since this bug only happens when 'Persistent Images' is on it was
introduced in some of the early merges with master and I never caught
it.
Thanks Daniel Salazar for helping with the bug hunting.
If we are using a mix node we still need to evaluate the BSDF lighting
even if scattering is successful.
Note: this was working for branched path (probably an oversight when
branched path support was introduced for baking, a good oversight though
;)
The bug was caused by using negative numbers as the end for playing forever (or until the end of the sound is reached) in the library. This was used with speaker objects which have an end of FLT_MAX now instead and the negative number interpretation was removed. I hope this doesn't break anything else.
Fixes T40027. This means we get more CPU usage again when using multiple CUDA,
but the impact on performance is too big a problem with the current code.
Instead of 95, we can use 145 images now. This only affects Kepler and above (sm30, sm_35 and sm_50).
This can be increased further if needed, but let's first test if this does not come with a performance impact.
Originally developed during my GSoC 2013.
