of the active object in the 3D view. This was due to sharing a global G.moving
flag to indicate that transform is active, now it's only set per transform data
type so different editors don't influence each other.
Crash happened in ED_view3d_calc_zfac and happend in cases operator was invoked
from a region different from RGN_TYPE_WINDOW.
For a transformation zfac is only used in convertViewVec in cases region is
RGN_TYPE_WINDOW, so solved by just adding extra check in calculateCenter
for this particular case.
generator with a local one. It's not thread safe and will not give repeatable
results, so in most cases it should not be used.
Also fixes#34992 where the noise texture of a displacement modifier was not
properly random in opengl animation render, because the seed got reset to a
fixed value by an unrelated function while for final render it changed each
frame.
edit mode
My earlier fix for [#33974] (in r.54061) was causing some problems where
manually specified roll values on horizontal or angled bones were getting reset.
This could be nasty as you might not notice the changes for a while (especially
when using stick bones without axes displayed).
I've now put in place a hacky compromise solution which should catch both of
these situations nicely. For z-axis (i.e. vertical) movements, the r.54061 fix
is used, while for everything else (moving or just touch-n-go), the old setting
is used.
For example, if you're making a chain of bones (e.g. for a spine) by extruding
the tip joint of an initial bone, the bone rolls would be: 0 (for the initial
bone), 180, -180, 180, -180, etc. This has the undesirable effect of causing
B-Bones to twist to match the roll values at the other end of the bone.
The fix here seems to improve the situation in this case: bone roll values don't
flip or change anymore (in fact, the bone axes stay perfectly aligned now, as
they should). It also doesn't seem to cause any problems in other common cases I
checked.
using numeric input
When using numeric input to move strips, the strip extent clamping code could
end up prematurely truncating one endpoint. This was because the clamping code
uses the values of the other end (e.g. end for start, and start for end) as one
of the limits on its allowable range to prevent inverted strips.
Now we just set these values twice - the first time, one of the endpoints may
still get truncated (while the other one will be able to go to its correct
value), then the second time both will get set correctly (and validated too).
Disconnected bones can be translated in pose mode but this translation
cannot be applied to the iTaSC representation of the armature because
there is no joint associated with it. As a result, moving disconnected
bones had no effect. The bug fix is in two parts:
1) manual or rna change in the armature pose will cause automatic
rebuilding of the iTaSC scene
2) the iTaSC scene is now built from the current pose instead of
armature rest pose
Particle combing didn't always respond as expected. The combed effect was
depending on the center of object in view, instead of on the center of
selected hairs. That made combing in certain close ups impossible.
Same was actually true for transform tools for hairs!
And even worse - there was an optimize break in calculating center
which wasn't true even. Causing centers for transform to fail similar
in other cases.
The issue was caused by SEQ_BEGIN macro modifying sequence's depth
which ruined transformation routines. Used own DFS instead which
doesn't modify sequences.
Also corrected some typos in api and comments.
