The simplest way of handling mirroring in multi-paint is creating a
uniform symmetric selection and relying on existing symmetric weights
to direct changes to the appropriate vertex groups. This already works
if mirror bones are selected manually, and can be made easier to use
by doing it implicitly.
Use the collective weight when using blurring.
This brings blur in sync with the rest of multi-paint modifications.
Also, blur has no business calling `defvert_verify_index` anyway when
it simply wants to read weights.
Similarly, the displayed weight distribution should be used as the
target of brush application instead of the invisible active group.
Multi-paint is split into a new function because all the calls to
defvert_verify_index at the top of the old code should never be
done in multi-paint mode.
Since the coloring uses sum or average of the weights of all selected
groups, the weight pick tool should also use that instead of reading
the weight of the single active group that you can't see.
This condition can actually happen quite often if weight painting for
a rig that uses separate control bones, so the color shouldn't be so
bright that it's hard to look at for a significant amount of time.
The threaded code is twice quicker now (from an average of 20ms/frame to 10ms/frame
while baking 10000 particles here e.g.)!
Think this is mostly due to usage of 'dynamic' scheduler in OMP code though,
from my experience so far this tends to have dramatic effects over performances,
static scheduler is usually much much more efficient.
Problem is actually similar in both engines - in some cases, we changed
'natural' quad splitting order to alternative one, without properkly 'notifying'
UV/VCol/other tessface data about it.
So code would use a 'wrong' triangle of UVs etc.
Fix for Cycles was committed by sergey as rBa6eae7339190d1.
The issue was discontinuity in logic when importing vertices from blender
and then importing data layers regardless of how we split the face. Quite
interesting we didn't notice this issue before.
Thanks Bastien for the investigation, based on D1742 but redid it to make
patch a bit more clear to follow.
LoopTri changes in 2.76 calculated all tangents as triangles,
this gave different results though in most cases it was hard to notice.
Though no bugs were reported we should keep our tangents compatible with other users of mikktspace.
Specifically, when only one bone is selected and it's not really active.
(With multiple bones on the other hand that behavior is forced on,
since multi-paint can't modify purely zero weight verts and that's important.)
There is no function pointers in OpenCL specification. For as long
as we want to support this platform we should follow the specifications.
While the code is not totally optimal now, it should not be that huge
of performance issue on CPU since it does jump tables just nicely, so
it's not that much extra computation here.
Now image will be opened for while render session is active, this is
needed to keep image cache working correctly. But stopping render
should now release all files descriptors.
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.
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.
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
This reverts commit b5bd39b518.
This is problematic because it means minor differences in system headers can cause errors
(glew in this case errored for me both with system and Blender's bundled version).
Developers can enable -Werror=* locally for warnings that aren't reliable across different systems.
