Blender Git Commits

Cycles: Add optional probabilistic termination of light samples based on their expected contribution

In scenes with many lights, some of them might have a very small contribution to some pixels, but the shadow rays are traced anyways.
To avoid that, this patch adds probabilistic termination to light samples - if the contribution before checking for shadowing is below a user-defined threshold, the sample will be discarded with probability (1 - (contribution / threshold)) and otherwise kept, but weighted more to remain unbiased.
This is the same approach that's also used in path termination based on length.

Note that the rendering remains unbiased with this option, it just adds a bit of noise - but if the setting is used moderately, the speedup gained easily outweighs the additional noise.

Reviewers: #cycles

Subscribers: sergey, brecht

Differential Revision: https://developer.blender.org/D2217

Cycles: Add smoothing option to the Brick Texture

This option allows to create a smoother transition between Bricks and Mortar - 0 applies no smoothing, and 1 smooths across the whole mortar width.
Mainly useful for displacement textures.

The new default value for the smoothing option is 0.1 to give some smoothing that helps with antialiasing, but existing nodes are loaded with smoothing 0 to preserve compatibility.

Reviewers: sergey, dingto, juicyfruit, brecht

Reviewed By: brecht

Subscribers: Blendify, nutel

Differential Revision: https://developer.blender.org/D2230

Fix T49846: OpenCL rendering compilation failure

Cycles: Implement texture coordinates for Point, Spot and Area Lamps

When using the Normal output of the Texture Coordinate node on Point and Spot lamps, the coordinates now depend on the rotation of the lamp.
On Area lamps, the Parametric output of the Geometry node now returns UV coordinates on the area lamp.

Credit for the Area lamp part goes to Stefan Werner (from D1995).

Cycles: More workarounds for weird crashes on AVX2

Oh man, is it a compiler bug? Is it something we do stupid?

For now more crap to prevent crashes. During the conference will talk to
Maxyn about how can we troubleshoot such weird issues.

Cycles: Another attempt to fix crashes on AVX2 processors

Basically don't use rcp() in areas which seems to be critical after
second look. Also disabled some multiplication operators, not sure
yet why they might be a problem.

Tomorrow will be setting up a full test with all cases which were
buggy in our farm to see if this fix is complete.

Cycles: Fix compilation error of AVX2 kernel without SSE math

Cycles: Completely disable transform SSE for now

Was causing issues on another frame.

On a tight schedule, disabling for now so artists are happy.

Still looking into root of the issue!

Cycles: Fix crashes after recent optimization commits

There is some precision issues for big magnitude coordinates which started
to give weird behavior of release builds. Some weird memory usage in BVH
which is tricky to nail down because only happens in release builds and GDB
reports all variables as optimized out when trying to use RelWithDebInfo.

There are two things in this commit:

- Attempt to make vectorized code closer to original one, hoping that it'll
eliminate precision issue.
This seems to work for transform_point().
- Similar trick did not work for transform_direction() even tho absolute
error here is much smaller. For now disabled that function, need a more
careful look here.

Cycles: Fix for fix (tm)

Sorry guys, for some reason read the expression back-to-front
and did wrong fix :S

Cycles: Fix typo in previous commit for BVH improvements

Cycles: Enable SSE math optimization for AVX kernels

This gives about 5% speedup for AVX processors.

Benefit of such optimization on other microarchitectures is still
under investigation.

Cycles: Use new SSE version of offset calculation for all QBVH flavors

Gives up to ~1% speedup again.

While it seems to be small, still nice since the code now is actually more
clean that it used to be before.

Cycles: Move QBVH near/far offset calculation to an utility function

Just preparing for new optimization to be used in all traversal implementation.

Should be no measurable difference.

Cycles: BVH-related SSE optimization

Several ideas here:

- Optimize calculation of near_{x,y,z} in a way that does not require
3 if() statements per update, which avoids negative effect of wrong
branch prediction.

- Optimization of direction clamping for BVH.

- Optimization of point/direction transform.

Brings ~1.5% speedup again depending on a scene (unfortunately, this
speedup can't be sum across all previous commits because speedup of
each of the changes varies from scene to scene, but it still seems to
be nice solid speedup of few percent on Linux and bigger speedup was
reported on Windows).

Once again ,thanks Maxym for inspiration!

Still TODO: We have multiple places where we need to calculate near
x,y,z indices in BVH, for now it's only done for main BVH traversal.
Will try to move this calculation to an utility function and see if
that can be easily re-used across all the BVH flavors.

Cycles: Avoid branching in SSE version of intersection pre-calculation

Similar to the previous commit, avoid negative effect of bad branch prediction.

Gives measurable performance up to ~2% in tests here.

Once again, thanks to Maxym Dmytrychenko!

Cycles: Implement SSE-optimized path of util_max_axis()

The idea here is to avoid if statements which could cause wrong
branch prediction.

Gives a bit of measurable speedup up to ~1%. Still nice :)

Inspired by Maxym Dmytrychenko, thanks!

Cycles: Add AVX2 path to subsurface triangle intersection

Similar to regular triangle intersection case. Gives about 3% speedup rendering
SSS object on my desktop,

Question: how to avoid such a code duplication in a nice way without speed loss?

Cycles: Cleanup, style

Cycles: OpenCL 3d textures support.

Note that volume rendering is not supported yet, this is a step towards that.

Reviewed By: brecht

Differential Revision: https://developer.blender.org/D2299