| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Differential Revision: https://developer.blender.org/D3732
|
|
Using near far and optionally clipping planes is
involved and not needed in many cases.
Rename so a simpler version of this function can be added.
|
|
Terms get/set don't make much sense when casting values.
Name macros so the conversion is obvious,
use common prefix for easier completion.
- GET_INT_FROM_POINTER -> POINTER_AS_INT
- SET_INT_IN_POINTER -> POINTER_FROM_INT
- GET_UINT_FROM_POINTER -> POINTER_AS_UINT
- SET_UINT_IN_POINTER -> POINTER_FROM_UINT
|
|
|
|
When using the 'normal' orientation, the normal would be ignored
if the plane couldn't be calculated.
Now use only the normal if the plane is zero length,
this was already done, just not in all cases.
|
|
|
|
See: T54858
|
|
|
|
Adds property poll function to transform.
|
|
|
|
Regression since 2.79b release
|
|
|
|
It's constraint not an orientation,
in transform context it can be inferred.
|
|
Also re-order for display purposes
|
|
|
|
We were using int's for bool arguments in BKE,
just to avoid having wrapper functions.
|
|
Other files with the same purpose already used 'query'.
|
|
|
|
Note that due to RNA get/setters issue, that one may actually add some
G.main usages to the total... But at least it's not hidden anymore in a
very low-level, dark corner of BKE pointcache code!
|
|
|
|
This commit actually adds some G.main... but at much, much higher level
than the ones it removes, so should still be better ;)
|
|
|
|
Sometimes one needs a *lot* of changes for a single G.main... :/
|
|
|
|
code.
From own previous G.main-busting commit.
|
|
Notes:
* Really need to address RNA setters case, end up adding way too much
G.main here these days... :/
* Added Main pointer into bAnimContext, helps a lot in anim code ;)
|
|
|
|
|
|
Some snap functions already exposed this.
|
|
This will allow greater control of the bvhtrees that are obtained, and helps identify problems.
It is also an additional step to unify the functions.
|
|
identifier type.
Reviewed By: @campbellbarton
Differential Revision: https://developer.blender.org/D3192
|
|
Extrapolation, and Influence
Applied similar fix to T54233 to get the "Record with NLA" feature working with
active action blending + influence settings. Extrapolation is explicitly ignored
though, as it shouldn't be used with this feature (i.e. it is already disabled
with the new strips and also on the animdata by default)
|
|
|
|
- Wasn't clear which functions handle edit-bones.
- Mixed both ebone and edit_bone in names.
- Didn't use ED_armature_* prefix for public API.
See P655 to apply to branches.
|
|
Was mixing up global/local coords
|
|
|
|
Tabs in middle of code (mostly for no reason / by accident).
|
|
|
|
|
|
Regression caused by earlier commits to improve the automerge behaviour.
In this case, the problems only occurred when moving a selected keyframe
forwards in time to overlap an unselected keyframe.
|
|
The other approach was causing too much error in some cases (e.g. favouring
the lower-valued keyframes). This fix should make the resulting curves less
bumpy/jagged.
|
|
|
|
This is to prevent problems with integer/enum properties getting invalid
values set.
|
|
|
|
unselected one would not merge the keys
This commit removes an earlier attempt at optimising the lookups
for duplicates of a particular tRetainedKeyframe once we'd already
deleted all the selected copies. The problem was that now, instead
of getting rid of the unselected keys (i.e. the basic function here),
we were only getting rid of the selected duplicates.
With this fix, unselected keyframes will now get removed (as expected)
again. However, we currently don't take their values into account
when merging keyframes, since it is assumed that we don't care so much
about their values when overriding.
|
|
tRetainedKeyframes
|
|
selected keys
that end up on the same frame
Currently, when scaling keyframes in the Dopesheet, if multiple
selected keyframes end up on the same frame post-scaling, they
would not get removed by the "Automerge" setting that normally
removes duplicates on the same frame.
This commit changes the behaviour so that when multiple selected
keyframes end up on the same frame, instead of keeping all these
around on the same frame (e.g. resulting in a column of keyframes
on different values), we will instead merge them into a single
keyframe (by averaging the values). This should result in a
smoother F-Curve with fewer "stair-steps" that need to be carefully
cleaned out afterwards.
Requested by @hjalti
|
|
|
|
Changing PET size while transforming stores the size in the
tool settings, but changing in the redo panel didn't.
|
