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 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 old value (1.0) was often too large in practice. When many collection
instances are created, the large empties create a mess in the viewport.
This adds a new preference setting in `Editing -> Objects -> New Objects`
called `Instance Empty Size`.
The value will be used as display size for new empties containing a
collection instance.
Reviewers: Severin
Differential Revision: https://developer.blender.org/D7650
Now the brushes have several new random settings and use curves to define the effect. The curves have been moved below the parameter to keep UI standards and extra curve panels have been removed.
{F8505387}
The new curves are:
* Hue.
* Saturation.
* Value.
New option to random at stroke level instead to random at point level for the following values:
* Thickness.
* Strength.
* UV.
* Hue.
* Saturation.
* Value.
Curves have been moved below the corresponding parameter and only are displayed in properties panel. Display the curves in the popover made it unusable.
{F8505392}
Also, the Pressure random has been renamed to Radius because the old name was not clear enough.
Reviewed By: mendio, pablovazquez
Differential Revision: https://developer.blender.org/D7577
All the driver-specific code in `fcurve.c` has been moved into a new file
`fcurve_driver.c`. The corresponding declarations have been moved from
`BKE_fcurve.h` to `BKE_fcurve_driver.h`.
All the `#include "BKE_fcurve.h"` statements have been investigated and
replaced with `BKE_fcurve_driver.h` where necessary.
No functional changes.
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).
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.
These socket types will be necessary for particle nodes.
The way these sockets are drawn can be changed separately.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D7349
Those new socket types will be necessary for particle nodes.
The main difficulty with adding these socket types is that they
are the first that reference ID data in their `value`.
Therefore, user counting code had to be added in a couple new places.
Reviewers: brecht, mont29
Differential Revision: https://developer.blender.org/D7347
This data block will be the container for simulation node trees.
It will be used for the new particle node system (T73324).
The new data block has the type `ID_SIM`.
It is not visible to users and other developers by default yet.
To enable it, activate the cmake option `WITH_NEW_SIMULATION_TYPE`.
New simulation data blocks can be created by running `bpy.data.simulations.new("name")`.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D7225
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
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
