This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule. This should be the final commit of the series of commits that
addresses this particular rule.
No functional changes.
Note this only changes cases where the variable was declared inside
the for loop. To handle it outside as well is a different challenge.
Differential Revision: https://developer.blender.org/D7320
While it might be handy to have type-less functionality which is
similar to how C++ math is implemented it can not be easily achieved
with just preprocessor in a way which does not have side-effects on
wrong usage.
There macros where often used on a non-trivial expression, and there
was at least one usage where it was causing an actual side effect/bug
on Windows (see change around square_f(sh[index++]) in studiolight.c).
For such cases it is handy to have a function which is guaranteed to
have zero side-effects. The motivation behind actually removing the
macros is that there is already a way to do similar calculation. Also,
not having such macros is a way to guarantee that its usage is not
changed in a way which have side-effects and that it's not used as an
inspiration for cases where it should not be used.
Differential Revision: https://developer.blender.org/D7051
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
The depsgraph was always created within a fixed evaluation context. Passing
both risks the depsgraph and evaluation context not matching, and it
complicates the Python API where we'd have to expose both which is not so
easy to understand.
This also removes the global evaluation context in main, which assumed there
to be a single active scene and view layer.
Differential Revision: https://developer.blender.org/D3152
2.8x branch added bContext arg in many places,
pass eval-context instead since its not simple to reason about what
what nested functions do when they can access and change almost anything.
Also use const to prevent unexpected modifications.
This fixes crash loading files with shadows,
since off-screen buffers use a NULL context for rendering.
Note that some little parts of code have been dissabled because eval_ctx
was not available there. This should be resolved once DerivedMesh is
replaced.
This is a different fix for the issue from D2088, preserving backwards compatibility
for IK stretching. The main problem with this patch is that this new behavior has
been there for a year, so it may break rigs created since then which rely on the new
IK stretch behavior.
Test file for various cases:
https://developer.blender.org/diffusion/BL/browse/trunk/lib/tests/animation/IK.blend
Reviewers: campbellbarton
Subscribers: maverick, pkrime
Differential Revision: https://developer.blender.org/D2743
Scaling a bone on the Y axis (for a stretch effect), wasn't supported by the IK solver.
Support this by solving as uniform scaled bones by matching the X,Z axis to the Y.
Requested by @pepeland, see D2088 for details.
* Rename Legacy to Standard, it's not being deprecated as far as I know.
* Make option to toggle off Location solving work with Standard.
* Make it converge a bit better in some cases by enforcing a minimum number of
iterations before giving up.
* Move IK solver choice out of bone panel, it's an armature level setting and
should be set there.
- building without python works again
- rename maxi/mini to i_max/i_min (so thay are available for function names)
- some minor edits to IK stretch setting (no functional changes).
This affected legacy solver. Note that even if I don't expect any, this fix *may* break some other IK setups, so animators, please check your IK rigs using legacy solver. ;) Easy to revert if needed, anyway.
Note that iTaSC solver is also buggy with some scaled parent, but here IK'ed bones just can’t get scaled in any way (either from parent or from there own transformation)... Will try to find what's happenning, though the code is even harder than legacy solver to follow :/
inconsistent with similar functions & math notation:
mul_m4_m4m4(R, B, A) => mult_m4_m4m4(R, A, B)
mul_m3_m3m4(R, B, A) => mult_m3_m3m4(R, A, B)
For branch maintainers, it should be relatively simple to fix things manually,
it's also possible run this script after merging to do automatic replacement:
http://www.pasteall.org/27459/python
Spline IK and Auto-IK working together on the same bone chain could
crash due to the somewhat hacky way that they were sharing the same
list for the "iktree" forest. Resolved by doing what I should have
done from the beginning, and made Spline-IK save its ik chains off
into a separate list.
While this fixes the crash, it might be worth investigating outright
disabling this from working in this case, since it can be a bit
confusing to have it appear to not work.
