| Age | Commit message (Collapse) | Author |
|---|
|
Allows compiling with newer Python versions.
Also add missing decref when compiling as a py-module.
|
|
Revise the logic here to be more robust when keyframes with
similar-but-different frame numbers (e.g. 70.000000 vs 70.000008)
would cause the search to go into an infinite loop, as the same
keyframe was repeatedly found (and skipped).
|
|
Tweak the bias from the previous fix a bit to be more backwards compatible in
some scene. In the end which way we round is quite arbitrary, but keeping the
case where the texture coordinate is exactly zero the same seems better.
|
|
|
|
*note: make a complete test scene
|
|
Macro makes debugging difficult. And in that case I was escaping from the style used in Blender
|
|
|
|
This would bring problems with dupli objects
|
|
The macro got a little strange, but it's better than using the MEM_mallocN inside a loop, or repeat the lines
|
|
The const key is required by compiler to avoid warning
|
|
Proxies"
The option has always (un)set the "Overwrite" flag on all strips. Calling
it "Override" seems misleading, since even when unchecking it, it overrides
whatever was set on the selected strips. It really just (un)sets the
"Overwrite" flag, and now it is also labeled as such.
|
|
|
|
In the reported example it seemed reasonable to apply this change.
But it causes a much more common case (selecting projections)
to be split into 2x islands.
Resolves T50970
|
|
|
|
|
|
This makes sense when we want to avoid float precision error
for near co-linear edges. OTOH, this is an arbitrary decision,
so keep functions separate.
|
|
|
|
That problem occurs because of the imprecision of `short int` (16 bits).
The 3d coordinates are converted to 2d, and when they are off the screen, their values can exceed 32767! (max short int value)
One quick solution is to use float instead of short
The snap code is actually a little tricky. I want to make some arithmetic simplifications in it
|
|
|
|
The only similarity between these functions is that both serve to snap.
However their codes are totally different from one another.
So by separating these functions, it:
- removes the need to put several conditions;
- simplifies and
- optimizes the code
|
|
Alembic's "inherits transform" flag wasn't taken into account when
constructing the parent object relations.
|
|
* Display a warning above the pose list if the pose library is in an invalid
state (i.e. when it has keyframes but no pose-markers associated with those
keyframes). This warning prompts users to run the "Sanitize Pose Library Action"
operator, which should fix up such issues.
* "Sanitize" operator now creates unique names for each newly create pose
marker it generates, including the frame on which it found the pose
|
|
|
|
IN and OUT parameters cannot be edited
The problem here was that the "frame_start" and "frame_end" RNA properties of
the Stepped FModifier were shadowing/overriding "frame_start" and "frame_end"
properties of the base FModifier. As a result, when the range() callback
for the In/Out parameters (defined as part of the base FModifier) checked
it's start/end properties, they were always still zero, meaning that the
acceptable range for the In/Out parameters was 0 -> 0 = 0.
Note:
If you've got old files with this problem, you'll need to manually click on
the frame_start/end properties to flush out the old values. It's probably
not worth the effort of applying a version patch for this (given that this
modifier is not one of the most often used ones AFAIK).
|
|
As with Strip Time, the updates here would get triggered before the
autokeying had a chance to record the unkeyed values, making it impossible
to autokey.
|
|
The issue was caused by combination of following factors:
- Clipboard cleanup function will pass node tree as NULL to node free
function.
This is fine on it's own, we don't have tree in clipboard.
- Node free function will call node storage cleanup only when there is
a non-NULL node tree.
This is somewhat weird, because storage cleanup does not take node
tree as argument.
So the solution here: move node storage cleanup outside of check that
node tree is not NULL.
|
|
|
|
Document to avoid confusion when called from Python.
|
|
Limit select fails with circle and border select.
Regression in 2.76
|
|
This was serious bug actually, probably a crasher in case you free
original or copy after duplication...
|
|
particles' scene and object pointers.
imapaint's clone and canvas are refcounting Image usages.
And particle's editsettings' object and scene seem to be pure runtime
data (they are reset to NULL in readcode), so resetting them to NULL
here as well.
|
|
|
|
LineStyle usercounts.
Really, really, really need to get rid of this usercount handling
everywhere, hopefully incomming ID copying rewrite will help sanitize
that mess. But fix was needed for 2.79 release!
|
|
While this is handy for image sequences, it's totally meaningless for movie files.
|
|
The code was somewhat weird: it was first copying border/crop settings from
the "source" scene, then was checking border settings of the current scene
and only then was copying border from "source" scene.
Now we first copy border/crop flags, then copy border from source and then
check whether border is a full-frame.
|
|
|
|
The loop running with no events didn't sleep.
Now wait for events when paused.
|
|
Note that bpy.data access makes more sense here,
but better not crash when called from Python.
|
|
|
|
|
|
Auto & aligned handles wouldn't restore to their correct locations.
Note that a more direct fix for the bug is possible
(storing the handle locations to restore on cancel).
But that still gives some odd behavior, see code-comments for details.
|
|
|
|
The default anisotropic tangent computation could fail in some cases,
leading to NaNs and artifacts. Use a simpler formulation that doesn't
suffer from this.
|
|
|
|
Fix some cases that still assumed there to be a global DPI, instead of a per
window DPI that needs to be set before reading U.dpi.
|
|
For now just make new depsgraph do similar updates to the old one.
See bug report for more detailed information about what was going on.
|
|
render
Move check for psys render data before it is actually requested for creation.
|
|
The issue was caused by combination of following factors:
- Blender Internal viewport render can not distinguish between which parts of
main database changed, so it does full database re-sync when anything is
tagged for an update.
This way, if any NodeTree (including compositor) is changed, Blender Internal
viewport is tagged for full render database update.
- With old dependency graph, scene-level drivers are evaluated on every
iteration of scene_update_tagged, even if nothing is tagged for an update.
This causes compositor drivers be evaluated quite often.
- Driver evaluation checks whether value was changed, and if so it tags
corresponding ID type as updated (this is what was telling viewport to do
render database update).
This check was quite stupid: current property value was checked against the
one coming from driver expression. This means, if driver value is outside
of the hard limit range of the property, the property will always be
considered updated.
The fix is to compare current property value against clamped value from the
driver.
|
|
Otherwise, there would be no way to load a bunch of pictures with
'sequence pattern' in name in a single operation.
Related to T51778.
|
|
New dependency graph is tacking root bone into account when building the graph.
This is required in order to get proper dependencies between bones. so we can
reliably use bones as targets from the same rig (and even indirect relations
via external objects). This forces us to tag relations for update when we change
root IK chain bone.
Since relations rebuild is not fully trivial operation, we only do it for
the new dependency graph. In the future it'll be nice to avoid whole graph
rebuild for such cases, but that's mentioned as a TODO.
|
