Basically layer_collection_sync was calling BKE_base_eval_flags right away while
iterating over the bases.
However when a parent/sibling collection is to influence the collection flag of
an object that exists in more than one collection, it is too late since we
deselect the object in BKE_base_eval_flags right away.
Related to T64312.
Reviewers: sergey, brecht
Differential Revision: https://developer.blender.org/D5243
`layer_used` runtime data, which controls the drawing of dots in the UI was not getting refreshed properly.
This used to happen in the drawing code, but was no longer working for reasons explained in:
{rB2b09062defa093a243b5fe64b099accb07b440a3}
The solution was to update each layer manually in the operators:
* ARMATURE_OT_bone_primitive_add
* ARMATURE_OT_delete
* ARMATURE_OT_dissolve
* ARMATURE_OT_fill
* ARMATURE_OT_merge
* ARMATURE_OT_separate
* ARMATURE_OT_bone_layers
* POSE_OT_bone_layers
Differential Revision: https://developer.blender.org/D5281
Applying/undoing incremental changes didn't fit well when
mixed with periodic snapshots from mem-file undo.
This moves to a much simpler undo system.
- Uses array storage with de-duplication from `BLI_array_store`.
- Loads the buffer into existing text data,
for better performance on large files.
- Has the advantage that Python operators can be supported
since we don't depend on hard coded undo operations.
Solves T67045, T66695, T65909.
Update the default init step values to be the same for all caches.
This is actually a small hack as these values are not used on the
creation of the first cache. But the default init value is 1, so this
will not be noticeable anymore.
Reviewed By: Brecht
Differential Revision: http://developer.blender.org/D5271
We only had a very limited, specific handling of that in collection
duplication code, but this has to be handled at a much more general
level in Object copy code itself, since it makes no sense to duplicate
rigidbody object data without adding new copy to relevant rigidbody
collections...
WARNING: This is a fairly risky rework of rigidbody handling logic
when copying an Object data-block. It is *NOT* considered safe enough
for 2.80 release.
I tried to take into account copy flags to not mess with other IDs
(collections) when we are copying outside of Main, and also not do deg
tags when this is forbidden, but risk of something going wrong here is
too high...
The dvert layer was not assigned to the mesh data if it had to be
created by the dpaint modifier.
Reviewed By: Brecht
Differential Revision: http://developer.blender.org/D5263
Was a mistake in normals calculation: need to consider all grids for correct
average in the center of the face.
Reviewers: brecht
Reviewed By: brecht
Maniphest Tasks: T66712
Differential Revision: https://developer.blender.org/D5254
Particles can not be used with a destructive modifiers, so we can not
maker such configuration fully reliable.
Not sure this specific setup ever worked in 2.7x, maybe DM index was
somehow reset somewhere in particle system in older Blender version,
or maybe all of Blender version were crashing.
Anyway, seems to be very easy to avoid obvious index past the array
boundary in the mapping,
Reviewers: brecht, zeddb
Reviewed By: brecht
Maniphest Tasks: T66812
Differential Revision: https://developer.blender.org/D5257
This was caused by loose pointers.
This diff takes care of clearing the fields of other bones before deleting the pchan.
Reviewers: brecht, sergey
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D5258
The issue was the the copy data function didn't copy the active canvas number.
So it would always be 0 and thus use the first canvas when trying to bake.
Also fix not copying unused type data (unused canvas/brush settings).
Reviewed By: Brecht
Differential Revision: http://developer.blender.org/D5220
It should be based on the mesh bounds before modifier stack evaluation, but
some modifiers were causing it to be recomputed. The flag to disable texture
space recomputation was not preserved through modifier evaluation.
Differential Revision: https://developer.blender.org/D5225
Seems the deform group index and deform vertices went out of sync somehow.
Added extra NULL pointer check, which seems to be safe and matches checks
in other places in the neighbourhood.
When `BKE_mesh_new_from_object()` cannot convert an object to a mesh, it
returns `NULL`. This case was not handled at all in
`BKE_mesh_new_from_object_to_bmain()` or `curvetomesh()`, causing a
segmentation fault.
This commit fixes the segmentation fault, and leaves the curve object as
a curve object.
Reviewed By: mont29, brecht, sergey
Differential Revision: https://developer.blender.org/D5217
I don't know if it was the intended behavior or not, but having brush
and canvas data at the same time with dymanic paint, would lead to the
object trying to act as a brush and a canvas at the same time.
We can't currently handle this with the new depsgraph, and it could
legitimately lead to bad feedback loops.
So now, to be more consistent with the GUI, I've made it only use the
current set type (brush or canvas) as the final type of the object.
That is, you can only have a object be a brush or a canvas, not both at
the same time.
Don't update animdata after rendering scene
Rendering host scene from sequencer is not supported, removed code is unnecessary.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5199
Previously in 2.79 we were using a specialized drawing using derivedMesh.
Now the subsurf modifier tag each center vertex as facedot and let the
DRWManager pick it up.
Some modifiers (deforming ones) do not clear the tag so we can use this
technique even if there is deforming modifiers after subsurf modifiers.
Moved the caching code from direct calls in DNA to dependency graph.
In fact, not much was needed to be done apart form removing the direct
cache updates. The rest seemed to work fine.
Possible to avoid full sound file re-load, but doesn't seem this is
causing any issues.
Now the simplify code works correctly in 3D space. Before it was trying
to project the strokes down into a local 2D space, but that didn't work
nicely for strokes with overhangs or big changes in the stroke
direction.
The code in question was simplified as well which lead to some nice code
reduction.
Reviewed By: Antonio Vazquez
Differential Revision: http://developer.blender.org/D5183
Make sure particle system edit never points to a modifier or particle system
which becomes inactive.
This is needed because copy-on-write will change pointers of them and those
pointers are supposed to be restored from particle system evaluation. But
since the particle system is disabled it never updates pointers.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5180
The issue was that the end point would be extrapolated and it would lead to
very high values if the curve had a near inf slope. Now we use the actual end
point value and only extrapolate values that are outside of the start and
endpoint range.
Differential Revision: https://developer.blender.org/D5151
CDData checking on file load was not taking into account deprecated
CD_MTEXPOLY datatype, which unfortunately shows same weird glitch as
CD_PAINT_MASK and CD_FACEMAP ones...
Note that it was annoying (due to amount of warnings in console), but
totally harmless, since that data type is just deleted anyway.
This commit also generally cleans up the CD_MTEXPOLY deprecation code, we
have a system to handle that, let's use it, instead of defining local
static values to replace it...
Two issues here:
- Evaluated object data is to only be updated for selection only after modifier
stack is done its job. Otherwise it's possible to have selection batch update
called on an input data, at the same time as original object data is being
evaluated.
- If object's modifier stack did not create its own evaluated mesh (in case
when there is no effective modifiers, for example) can not update selection
on object's data, as it might cause threading issues between objects sharing
same data.
