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
* 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
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.
Hashed Alpha transparency offers a noisy output but has the benefit of being correctly ordered. Noise can be attenuated with Multisampling / AntiAliasing.
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.
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.
The "fix" happened due to a mistake in copy-on-write commit, that mistake solved
preview render but broke something else.
This reverts commit 45720922f7.
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!
UVs need specific data in the VBO, which is not computed unless the
shaders assigned to the mesh actually use UVs. When adding UVs to the
shader, the VBOs were not being recomputed to include the required data.
This adds a DEG relation between the shader and the mesh, and recomputes
the required data if the shader changed.
Thanks Sergey, for all the DEG stuff...
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.
A pointer to the uniform data for the empty drawing was being freed
before the actual draw call, which invalidates the uniform.
This makes the data only be freed after drawing.
