Blender Git Loki

Libmv: Solve some strict warnings in tests

GTests: split array_utils tests

CMake: check for LLVM static library by default

Even when static option isn't enabled, use the static library path if the dynamic library isn't found.

Weight Paint: Add lock-aware normalize

D1713 from @angavrilov (with own edits)

The way current weight paint code works is that instead of making normalization lock aware, a separate `enforce_locks` function is called to do a different kind of normalization, hoping that by the time real normalize is called, there is nothing for it to do. The problem is that:

- That different normalization is based on adding the same amount to all unlocked groups, whereas true normalize uses multiplication to preserve ratio between them. The multiplicative approach should match the way weights operate better.
- If `enforce_locks` fails to achieve perfect normalization, true normalize will change locked groups.

Try to fix this by replacing `enforce_locks` with true lock-aware normalization support.

Supporting locked groups in normalize means that freezing the active group can make full normalization impossible if too much weight was added or removed, so it may be necessary to do two normalize passes. This is similar to how enforce_locks operates.

Also, now there is no need to go through the multi-paint branch just because of the locks. In the actual multi-paint case, the same normalize code can be used via a temporary flag array that represents the union of selected and locked groups.

User-visible effect should be:

- Auto-Normalize doesn't change behavior vertex to vertex depending on whether it has any locked groups.
- It never changes locked groups; if you lock some groups and start painting with seriously non-normalized weights, it's assumed you intended that.
- It never adds vertices to new groups, since the computer can't do that intelligently anyway - it was especially broken in case of mirroring.
- It always acts to preserve the ratio between groups it changes, instead of (sometimes, see point 1) adding or subtracting the same amount.

GTests: array_utils

BLI_array_utils: add binary and/or functions

Ignore const qualifier when comparing types

Cleanup: style

rather then ? rather than

OpenGL: remove ARB_fragment_program comment

This a list of OpenGL extensions used. Minus one thanks to
kevindietrich?s smoke work!

https://developer.blender.org/D1694

Transform: no need to store distance to snap point

Compare squared distance to snap target since the value is only ever used for comparison.

Fix T29153: Rotate & scale ignore snapping points

Checking for 'Closest' here isn't needed since
TransSnap.snapTarget callback is already ensuring the selected target is the closest.

Also don't reuse the pre-calculated distance,
since its only valid to do this when there are no snap points
and this isn't a significant gain to avoid the extra calculation - run once per update.

UI: use a callback for the progress tooltip

Avoids constructing tip text and storing it when its not used.

Also quiet divide by zero warning when no progress was made.

UI: redesign of the progress bar.

A picture is worth a thousand words: http://wiki.blender.org/index.php/
File:UI_progress_bar.png

Reviewers: #user_interface, brecht, dingto

Reviewed by: brecht, dingto

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

BGE: Allow access to light shadow settings with python

This patch adds a new API which allow us to access light shadow settings from python. The new API can be used to write custom GLSL materials with shadows.

Reviewers: brecht, kupoman, agoose77, panzergame, campbellbarton, moguri, hg1

Reviewed By: agoose77, panzergame, campbellbarton, moguri, hg1

Projects: #game_engine

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

paint_cursor: OMP -> BLI_task.

Bump boost to 1.60

CMake: clarify missing Python package message

Blender builds properly without extra Python packages,
avoid FUD for new devs.

Cleanup: spelling

Also use doxy formatting for warning/note.

Cleanup: style