in threaded depgraph updates and effector list construction.
Gathering effectors during depgraph updates will call the
psys_check_enabled function. This in turn contained a DNA alloc call
for the psys->frand RNG arrays, which is really bad because data must be
immutable during these effector constructions.
To avoid such allocs the frand array is now global for all particle
systems. To avoid correlation of pseudo-random numbers the psys->seed
value is complemented with random offset and multiplier for the actual
float array. This is not ideal, but work sufficiently well (given that
random numbers were already really limited and show repetition quite
easily for particle counts > PSYS_FRAND_COUNT).
Basically proxy colorspace didn't work well enough.
It is still a bit weird and mainly:
- Proxies for image sequences are built in the image color space.
- Proxies for movies are built in the movie color space.
This could be unified but would need some work in proxy build
to make it not just pipe frames from one FFmpeg context to
another but also apply OCIO on it.
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.
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
27d792fa9c) they can still make an action with the rest pose and use that
as the first strip.
Implements a more flexible internal connect function for standard nodes
(compositor, shader, texture). Allow feasible datatype connections by
priority.
The priorities for common datatypes in compositor, shader and texture
nodes are encoded in a simple function. Certain impossible connections
(e.g. color -> cycles shader) are excluded by giving them -1 priority.
Priority overrides link status: If a higher priority input can be found,
this will be used regardless of link status. Link status only comes into
play for inputs with same priority.
Reviewers: brecht
CC: sebastian_k
Differential Revision: https://developer.blender.org/D356
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
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.
For initial discussion see T38371
This commit organized panels for image editor to new tab categories dependent
on the image editor mode:
View Mode:
Tools - contains UV tools (currently only transform and UV Sculpting)
Scopes - contains scopes
Grease Pencil - contains Grease Pencil operators
Paint Mode:
Tools - contains brush options
Scopes - as above
Grease Pencil - as above
Mask Mode
Mask - contains mask tools
Scopes - as above
Grease Pencil - as above
Grease Pencil panel/tab now includes operators, not view options which have been
moved to the UI region on the right.
To make this work better, image editor toolbar now is of type TOOLS instead
of PREVIEW as was the case previously. A nice version patch makes sure all
works predictably, but opening newer files with older blender executables
could backfire.
This commit does not address which UV Tools will be included in the
Tools tab for the view mode, but does include some basic tools (transform)
and provides a class to inherit from to avoid conflicts with UV Sculpting.
Reviewers: brecht, dingto, sergey
Differential Revision: https://developer.blender.org/D315
Some int/float conversion warnings were disabled by buildsystems but
re-enabled by BLI_winstuff.h, the warnigns relate to conversions not
considered issues on other systems so better just quiet them.
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
