Mask slot still depended on regular slot to check some capabilities.
Some angle capabilities now only depend on the texture slot, not the
brush, so separate them and use the slot where appropriate.
This isn't so bad for until one goes re-posing the armature and then uses undo.
It is the same issue as with edit mode which was solved back in the days.
The getter of this matrix (actually, `BKE_object_matrix_local_get()`) was only correct
in case of pure-object parenting, bone parenting and such did not gave valid results.
Also cleaned up a bit setter code, was using as temp storage ob->obmat itself,
which is supposed to be a world matrix!
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D958
This reverts commit 1549fea9995c348bc14a9105df5e460644e2b33a.
After some further discussion with other developers in the team it becomes
clear there's no correct solution here. It is just more matter of what's
more convenient in particular case.
We're just going back to old code to avoid possible frustration with the
older files in newer blenders. This also means all HSV/HSL is considered
to be "linear" in the shading nodes.
Would be ported to 2.73 final.
Either ./blender-git or ~/blender-git should be used, but not
.~/blender-git. This patch fixes that, by choosing ~/blender-git,
in line with the last CLI argument.
This way we'll be sure (in debug builds) that regular BVH traversal is not used
for QBVH tree (could happen because of mismatch of logic in kernel and render).
The reason for this is that we don't sue SSE optimization for 32bit platforms
because of T36316.
Things to look into:
- Nail the root of the issue of that report
- Implement non-SSE traversal code for QBVH
Org code by robschia (Roberto Schiavone), first review by campbellbarton (Campbell Barton),
final review and minor changes by mont29 (Bastien Montagne).
Reviewers: cambellbarton, mont29
Subscribers: mont29, campbellbarton
Maniphest Tasks: T40930
Differential Revision: https://developer.blender.org/D638
The layers list and the Dopesheet channels now show color swatches for both the
stroke and fill colours now. This is useful when you've got layers that only
use either/or.
* Currently, these only get shown if the relevant opacity setting is high enough
for that aspect to contribute to the result.
* The sizing of these items could do with some more tweaking (especially in the
Dopesheet), as these may now be too small to accurately see and/or interact with.
* There are some potential issues when using near-gray (or actually, colours similar
to the list backgrounds, but that issue exists in other areas of Blender anyway.
(NOTE: At this stage, these changes are still experimental, and not for 2.73 yet)
Since I don't have a (pressure sensitive) tablet handy, I can't really test this
out, but apparently there is a bug which currently exists with the following description:
"Small Dots, when you do just one click a single GP dot is created, it´s fine but don't recognize the pen pressure, always the maximum value of thickness, and
It´s so easy create dots accidentally (even when you use the eraser, this dots appear spontaneously) and you start to have big screen-size-constant dots beside of you fine lines."
This commit just shuffles around the order of things a bit so that some of the misfiring
events might get skipped instead.
This commit includes a few things:
* It moves the Rake and Random flags from the brush to the MTex.
* The first change allows mask textures to have independent rake
support.
* Random rotation now has an angle value that controls the width of the
effect from the rake or default angle
* Rake and Random are now supported together.
Initially it was moved to allow setting keymaps of python defined menus
in C but looks like it breaks macro definition in python.
Thanks to Julian for tracking this down. It should fix T42485
Safe for 2.73...
This revert rB9b0ab890676790bb1e8e77797629b889ea66f69e - needed to set that threshold to a small
negative value to remove the last artefacts reported in T39735, but now I could not reproduce
any with the previous 0.0f value, so restoring it for the time being.
If this 'shadowed neighbor face' case re-appears, we can always choose a value in-between, like -1e-18f...
Seems the parent check didn't go deep enough and only checked single parent.
Now it checks the chain of parents which seems to be correct but requires
much more intense testing.