| Age | Commit message (Collapse) | Author |
|---|
|
This includes:
68ef679, d0ad48f, e913eab + 8d09ec6, 9630fa7, 4ce7d5c,
b839fb9, 43b5f0a, 4d47e75, 89c793f, b23a439, 0a3850f
de86b70, cfefc5d, 997b49a, 6919ffb, c1be7e1, 6ddd54f
7a9838b + 98abc80, 23fbc9f, 41dde55, 500088d, c2045ef
c31c8fa, 7461fea, d219312, 0844451 + c05896e, ef51b69
19935f0, b977cfd, 3c3c2cd, 9ecf73f, 20f7a34, f03df4f
2de9da6, ba81fb7, a7ab389, d7cff8f7
|
|
Testing for custom data availability with getVertData and index 0 fails
on assert for empty meshes (the index must be in valid range). Better
use getVertDataArray which has no requirement for specific index.
|
|
|
|
the same issue.
|
|
If you have two overlapping NLA strips it automatically blends between them.
However it was also blending between the first strip and the rest pose
(e.g. 0,0,0 for locations and 1,1,1 for scale).
This is ok if the blend mode is Add or Multiply since then you are adding onto
the rest pose, but for Replace you want to be able to mix between two poses
and not take the rest pose into account at all.
What this does is that to not do any blending for the first strip if it has
blend mode Replace. If someone wants the old behavior (from bugfix commit
27d792fa9ca1) they can still make an action with the rest pose and use that
as the first strip.
|
|
|
|
Issue of this bug is that most part of fftw is not thread safe, only compute-intensive fftw_execute & co are.
Since smoke was affected by this issue as well, a global fftw mutex was added to BLI_threads.
Audaspace also uses fftw in one of its readers (AUD_BandPassReader.cpp),
but this is not an issue currently since this code is disabled in CMake/scons files.
There was another threading issue with smoke, we need to copy dm used by emit_from_derivedmesh(),
as it is modified by this func.
Reviewers: sergey, brecht
Reviewed By: brecht
CC: brecht
Differential Revision: https://developer.blender.org/D374
|
|
|
|
|
|
|
|
|
|
|
|
Also remove outdated comments.
|
|
|
|
Animating large values with auto handles didn't work well,
(large variations on the Y axis would shrink handles).
|
|
|
|
|
|
F-Curves with large Y axis had strange behavior where the handles could
stretch out on the X axis rather then clamping as they do at smaller sizes.
|
|
also avoid calculating handle length when align isn't used.
|
|
|
|
|
|
|
|
Issue was caused by cycles setting scene frame which will update scene for
all the layers (not just visible ones) which confuses depsgraph making
objects which are needed as dependency are not really evaluated.
Made it so setting frame via scene.frame_set() which check whether update
need to be flushed to an invisible objects and do this if so.
Not ideal solution but seems to be safest at this point.
|
|
Issue was caused by curve orco calculation for rendering being freed
curve path and not calculating it back.
This left depsgraph in a state that it believed all the object data
is up to date but in fact some parts of data was freed by convert
blender.
Now made it so path is not being freed by render thread. This is
rather a workaround actually because ideally render thread need
to use copy-on-write here or at least use local cache here. But
current logic should be closer to what was happening in previous
release.
|
|
Issue was caused by undefined object update order and in some
cases NULL pointer will be de-referenced.
Added on-demand curve path calculation, just the same creepy call
of BKE_displist_make_curveTypes(). This violates DAG and might
end up in a difficult to troubleshoot race condition if there'll
be some issues with how dependencies are calculated in DAG, but
this is the easiest and safest way to solve the bug at this stage,
|
|
|
|
|
|
|
|
The issue was caused by the fact that sequencer used to cross-over effect
result with strips used for this effect, which is really stupid.
Now made it so strips which are used for effect inputs are not in the
render stack to be sure they would only be used by effect itself and
wouldn't be blended in any other way.
|
|
|
|
|
|
|
|
|
|
After recent seed improvements it makes tracking more robust
without speed loss.
|
|
Useful for cases when you need to create bunch of witness tracks.
|
|
|
|
It is possible that objects from dupli-groups depends on objects which are
not in the dupli-group. We do need this objects to be evaluated as well on
visible changes, so all dependencies for objects from the dupli-group are
met. Unfortunately, we don't have parent relations on this state, so we're
to use DFS over the whole DAG to gather such dependencies.
This is probably not so bad since visible update is called really rarely.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D326
|
|
|
|
This isn't a proper fix, curve_cache should not be NULL, but it makes it
possible to open the file at least.
|
|
Issue was caused by the change in FFmpeg options: some of them were
renamed, some moved to another class.
Made some tweaks to how options are passed to the FFmpeg which now
seems to be the same as ffmpeg.c.
|
|
Issue was caused by missing GLOBALHEADER flag set for audio stream.
Also made it so frame is getting filled with default, that's what
happening in ffmpeg.c.
|
|
|
|
|
|
|
|
This fixes a small compile error where MSVC9 complains about conversion from int to unsigned char.
|
|
|
|
|
|
|
|
|
|
correct.
The "premultiply" optimization here did not take the extrapolation into account.
|
