Among other things, they were missing library pointer, session uuid
initialization, etc.
Fix T74546: Corrupted nodegroups crash blender when copy pasting or
appending them.
Fix (unreported) asserts when undoing some production scenes (from
coffee run e.g.).
Initialy caused by rB0aac74f18f2d.
This error was introduced wit the change in commit https://developer.blender.org/rB6a850f3cc840
As the brushes were not created, all modes except Edit were broken.
Now, the brushes and palette are not created when load the file in versioning code, but when the mode is enabled.
Also, if the brush already exist, the parameters are not reset as it was done in the versioning code in order to keep user settings.
The same logic is used for the default palette.
This removes grease pencil brush creation/dat-block delete on load,
since this causes duplicate data-blocks.
Add assert to prevent this happening in the future
since the error is isn't obvious.
The file attached in the report has a cloth brush saved with a particle
mass of 0.0, which causes all sort of issues in the solver. I don't know
how that brush was created, but it does not seems to be possible to do
in the current version (reset values are correct, property limits are
correct and a default brush is created in versioning_defaults). This
resets all brushes with an invalid value to 1.0.
Reviewed By: jbakker
Maniphest Tasks: T75347
Differential Revision: https://developer.blender.org/D7698
Should prevent issue fixed by previous commit to happen again (since
read code, especially in undo case, is not really straight forward to
follow anymore).
Own error in cleanup from 5dcb6fb22f unintentionally
changed enum values. Although this code violated our own
rules to use explicit values to avoid this happening.
3DCursor is UI data (hence not expected to be affected by undo) that is
stored in actual data (Scene)... So it needs some special care during
undo.
New undo code now re-reads data into existing memory, which means
copying of 3DCursor data has to happen earlier in that case, when we
still have both old and newly read data available.
This crashes with ASAN enabled.
```
==39366==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges [0x6230000ae848,0x6230000ae85a) and [0x6230000ae851, 0x6230000ae863) overlap
```
The problem was that in direct_link_id_restore_recalc, recalc_undo_accumulated
should contain the changes from the target state to the current state. However
it had already been cleared at that point, to start accumulating changes up to
the next undo push.
Delaying the clear of this flag seems like the obvious solution, but it's hard
to find the right place for that (if there is one). Instead this splits up the
flag into two separate variables.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D7402
* Implemented the algortihm that would merge vertices to the weighted
center between them.
* Exposed the merge threshold to the user.
The new default tolerance is 0.0001 (versionning code ensures that
previous default value remains in use to avoid any change in existing
files).
Review and minor changes/cleanups from Bastien Montagne (@mont29).
Removal of 'Translation' checkbox. Enable translation options when selecting non-English languages.
Differential Revision: https://developer.blender.org/D7210
Reviewed by Brecht Van Lommel
These changes only have an effect when the experimental Undo Speedup preference
is enabled.
* For DEG_id_tag_update, accumulate recalc flags immediately before the undo
push happens instead of afterwards. Otherwise the undo state does not
contain enough flags, and the current state may contain too many flags.
This also means we call DEG_id_tag_update after undo with the accumulated
flags to ensure they are flushed to other datablocks.
* For undo, accumulate recalc flags in id->recalc and clear accumulated flags
immediately. Not clearing would cause circular behavior where accumulated
flags may never end up being cleared.
This matches what happens after an undo push where these are also cleared,
indicating that the undo state and current in-memory state match exactly.
* Don't change id->recalc of identical datablocks, it should not be needed.
There is one exception for armatures where pointers across datablocks
exist which otherwise would cause problems. There may be a better solution
to this but it seems to work in agent 327 production files.
* This contains a change in undofile.c to avoid detecting all datablocks as
changed for the first of the two undo steps, where we restore to the state
of the last undo push before going to the one before.
Without this the whole system is much less efficient. However this is unsafe
in the sense that if an app handler or operators edits a datablock after an
undo push, that change will not be undone.
It can be argued that this is acceptable behavior, since a following undo push
will include that change and this may already have unexpected side effects.
Ref T60695
Differential Revision: https://developer.blender.org/D7339
Other types of datablocks pointing to UI datablocks is unsupported, so
there is no need to store them in fd->libmap. With the experimental undo
speedup enabled preserving such pointers was done. But it didn't work in
2.82 and such pointers are easily lost in cases other than undo.
Differential Revision: https://developer.blender.org/D7329
Feature can be enabled or disabled in timeline view menu item "Show F-Curves".
Author a.monti
Reviewed By: ISS
Differential Revision: https://developer.blender.org/D7205
