| Age | Commit message (Collapse) | Author |
|---|
|
issues.
The way we use it, UI_PRECISION_FLOAT_MAX is actually + 1 to get total
number of digits, and float only has 7 meaningful digits, so that define
shall be at 6.
|
|
GCC seems to detect uninitialized into function calls now, but then isn't
always smart enough to see that it is actually initialized. Disabling this
warning entirely seems a bit too much, so initialize a bit more now.
|
|
Interpolate rather than do alpha over mix, matching projection paint.
|
|
Caused select-mirror to fail with edges & faces.
|
|
Hopefully fix it actually, at least could not reproduce it anymore with
that changen, but Was already quite hard to trigger before.
We need a memory barrier at this allocation, otherwise it might happen
after preview gets added to done queue, so preview could end up being
freed twice, leading to crash.
|
|
|
|
|
|
Text search would not run in case there was no 'type' enabled in filter
buttons. Now instead consider that no types enabled == all types
enabled.
|
|
While drawing nice 'rounded' values is OK also for 'low precision'
editing like dragging and such, it's quite an issue when you type in a
precise value, validate, edit again the value, and find a rounded
version of it instead of what you typed in!
So now, *only when entering textedit of num buttons*, we always get the highest
reasonable precision for floats (and use exponential notation when
values are too low or too high, to avoid tremendous amounts of zero's).
|
|
|
|
|
|
|
|
|
|
minimum 96.
Since we added auto DPI on Linux, on some systems the UI draws smaller than before
due to the monitor reporting DPI values like 88. Blender font drawing gives quite
blurry results for such slightly smaller DPI, apparently because the builtin font
isn't really designed for such small font sizes. As a workaround this clamps the
auto DPI to minimum 96, since the main case we are interested in supporting is
high DPI displays anyway.
Differential Revision: https://developer.blender.org/D2740
|
|
|
|
This is a different fix for the issue from D2088, preserving backwards compatibility
for IK stretching. The main problem with this patch is that this new behavior has
been there for a year, so it may break rigs created since then which rely on the new
IK stretch behavior.
Test file for various cases:
https://developer.blender.org/diffusion/BL/browse/trunk/lib/tests/animation/IK.blend
Reviewers: campbellbarton
Subscribers: maverick, pkrime
Differential Revision: https://developer.blender.org/D2743
|
|
|
|
away from the object
No need to take into account font size here...
|
|
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.
|
|
|
