| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
Uses for view orientation for distance calculation, can give nicer results when you dont want twisting caused by changes in depth.
|
|
|
|
builds.
|
|
viewport.
|
|
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.
|
|
by Kevin Mackay (yakca)
Was one of our TODO's from the wiki.
|
|
remove MEM_sys_types.h which was a duplicate.
|
|
- mult_m4_m4m4 -> mul_m4_m4m4
- mult_m3_m3m4 -> mul_m3_m3m4
these temporary names were used to avoid problems when argument order was switched.
|
|
|
|
BKE_editmesh_bvh.h
|
|
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.
|
|
EditDerivedBMesh.tc -> em. ('tc' is odd name which isn't used elsewhere).
|
|
working if the object was rotated.
|
|
|
|
use for
mask/uv modes.
|
|
|
|
-> ED_view3d_calc_zfac() and have it return the zfac to use.
|
|
thanks!)...
|
|
enough.
|
|
made bone roll get compatible angle values with the original roll.
|
|
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.
|
|
style edits and typo corrections.
|
|
centers
|
|
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).
|
|
changed in pose mode.
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.
|
|
|
|
mid_v3_v3v3
|
|
|
|
Proportional editing of Objects in Object Mode didn't reset positions when
changing the circle influence size. Fix provided by Phillipp Oeser. Thanks!
|
|
|
|
|
|
|
|
mouse (grab tool)
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.
|
|
and t->obedit, now only use t->obedit.
- freeing bez-triple handle data was being done in a loop for many types which don't support bezier handle data.
|
|
(also NULL after freeing)
|
|
Invalidation was missed for:
- Strip (Un)Muting
- Changing speed effect
- Strip translating
|
|
semi-transparent strip
|
|
|
|
move a node into its own child frame (causing recursive parent loop).
also some minor code cleanup.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
