This commit hopefully fixes all glitches we had when bone was Z-aligned. Note that when you init a transform
with a Z-aligned bone and change it to be non-Z-aligned, you will still get some brutal roll change,
there is not much things we can do here afaik...
renders were broken.
This was caused by rB1a79abdad2443ff9f12e7efd95ee78a264a9d60a which
makes a copy of the render layer list for thread safety. The single
layer passed to this function is still in the original list though, so
to get the correct index it has to be looked up there. Otherwise no
active index is set and all layers are rendered every time.
It would include/exclude shadow depending on the pass being disabled/enabled,
but that should have no influence on the combined render result. Now it always
includes shadow.
The render operator invoke checks render layers, which can force the
render layer to be activated. This requires a notifier, which has to be
done in the operator itself (can't do this inside pipeline code).
It doesn't make sense to use zero-weighted tracks as a correspondences
in keyframe selection.
Such tracks are not guaranteed to be tracked accurately because their
purpose is to add reference points in 3D space without affecting the
solution.
Problem is that the particle systems in the cycles database are not
stored in a well-defined order. This means the particle_id for dupli
objects can not simply be assigned using a global running index during
sync.
Now the particle index is assigned locally for each particle system.
When transferring particle data to the device as a single texture, the
particle indices are offset based on the final order of particle systems
in the database.
Reviewers: brecht
Reviewed By: brecht
CC: Andreas80
Differential Revision: https://developer.blender.org/D352
This gives much worse results on mango footage (see 04_2e)
so disabling for now for until proper prediction model is landed.
The thing is, currently blender sends input coordinates as the guess to
region tracker and in case of fast motion such an early out ruins the track.
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.
Blender Internal shader nodes.
All nodes now use the `nodestack_get_vec` function to convert whatever
input values are connected to the desired type, instead of using the
stack values directly regardless of what they contain.
Note that this might break old node setups that have been adapted to the
faulty behavior, but as discussed in the bug report the 2.70 version is
the right time to fix this.
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.
