Before, the material name was used to filter the effect of the stroke, but after the last changes in the ID code, now it's not working.
After talking with @severin, we agreed to replace the material name with a pointer. Also, this fix a design issue when the materials were linked.
Related to T76594
Differential Revision: https://developer.blender.org/D7681 with some minor changes
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).
For newly opened 3D Views, the default would actually be 0.01m. But the
code to update the default for all existing 3D Views in the
startup.blend was missing. So the defaults were out-of-sync.
0.01m is the more reasonable default as agreed on by the UI team.
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.
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 adds an embedded node tree to the simulation data block dna.
The UI in the `Simulation Editor` has been updated to show a list
of simulation data blocks, instead of individual node trees.
The new `SpaceNodeEditor.simulation` property wraps the existing
`SpaceNodeEditor.id` property. It allows scripts to get and set
the simulation data block that is being edited.
Reviewers: brecht, mont29
Differential Revision: https://developer.blender.org/D7301
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
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).
