For FCurves where all the keyframes use the "simple" interpolation types
(i.e. Constant, Linear, and Bezier), we now use the old FCurve drawing
code that was used prior to the Easing Equations changes. This should
be generally faster in general.
When the "High Quality Line Drawing" option (View menu) is disabled,
the sampling rate (i.e. the size of timesteps to use when sampling
the FCurve for drawing it in most cases now) is set to be quite low
(i.e. at 0.1 frame increments). This amounts to at most 10 sub-steps.
In one test file (with a wide window), this had the effect of improving
the performance by over 3x. It's still not as good as a sampling-free
approach, but for this functionality is still needed for FModifiers,
so it's better that we can optimise this.
Small optimisation (which shouldn't have much of an effect) where we skip
complex handle calculations if all the handles/verts for a Bezier curve
segment are all flat.
Patch by Campbell (T40372 -> F91346)
When the active action is a NLA strip, the keyframe indicator colors for buttons
and the 3D view indicator (i.e. the current frame indicator changes color) didn't
work correctly. This was because they were still checking for keyframes in
"global" time space, whereas they needed to be applying NLA corrections to
"look inside" the remapped action.
In fact, any button controlling a whole array of values were broken
because they always only keyed the index of the single fcurve returned
by `ui_but_get_fcurve()`, now pass button's rna_index value instead.
Recent flag re-order broke it since bits overlap, but logic here was far too complicated & fragile,
Checked the type of each button when testing which direction to handle events as well as block direction.
Now store the block-flipped state as a flag.
It appears it's not really needed for convenient debugging when
using proper flags passed to the compiler. Basically, it is -g3
and set breakpoint to a function as if it's not in the namespace.
Not as if a code was any wrong, just it's possible to have more
clear solution for the issue i've tried to solve in the past.
The Mesh Tools have quite few crucial tools that're missing from the toolbar. This is the main one.
The tools that're here should also be reorganized a bit to introduce actual orgnization, as it's quite sporadic at the moment. Will do that later.
Nothing related to rigify actually, recent hack in py handling of IDProp (rB3346ab03)
was breaking integrity of IDGroup's listbase of children IDProps...
Took me hours to nail this down, should have bisected for once. :/
That's like really a bummer, because currently animation data for armatures
might want to use pose, and pose might be missing on the object.
This happens when changing visible layers, which leads to situations when
pose is missing or marked for recalc, animation will change it and then
object update will restore the pose.
This could be solved by the new dependency graph, but for until then we'll
do an extra pass on the objects to ensure it's all fine.
It's done in the scene_update_for_newframe() to solve possible issues with
the render engines as well.
This finally solves issues we had with Caminandes team, where Koro would be
at the scene origin instead of being properly posed.
too crowded.
UVs in the same layer can be used for many images. It used to be
possible to filter UV faces based on the image, but this is impossible
now due to the way the system works, so I added an option to allow
filtering UVs based on active material index.
Rationale on using option and not being smart here (options are bad tm)
is that for some workflows, such as preserving image space by using the
same image for many materials, people might want to turn this off.
layer index was being obtained for loop data types but we referenced
Tessface data types
NULLing those out since only the data offsets are used in edit mode and
address sanitizer complains about freed memory access.
Also minor comment in texpainting
Murmur2a is a very fast hashing function generation int32 hashes.
It also features a very good distribution of generated hashes.
However, it is not endianness-agnostic, meaning it will usually generate
different hashes for a same key on big- and little-endian architectures.
Consequently, **it shall not be used to generate persistent hashes**
(never store them in .blend file e.g.).
This implementation supports incremental hashing, and is a direct
adaptation of reference implementation (in c++):
https://smhasher.googlecode.com/svn-history/r130/trunk/MurmurHash2.cpp
That cpp code was also used to generate reference values in gtests file.
Reviewers: sergey, campbellbarton
Reviewed By: campbellbarton
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D892
