Things like pointers to particle systems, or softbody data being stored
outside of its modifier, make it impossible for internal modifier copy
data code to be self-contained currently. It requires extra processing.
In existing code this was handled in several different places, in
several ways, and alltogether fairly inconsistently. Some cases were
even not properly handled, causing e.g. crashes as in T82945.
This commit addresses those issues by:
* Adding comments about the hackish/unsafe parts `psys` implies when
copying some modifier data (since we need to ensure particle system
copying and remapping of those pointers separately).
* Adding as-best-as-possible handling of those cases to
`BKE_object_copy_modifier` (note that it remains fragile, but is
expected to behave 'good enough' in any practical usecase).
* Remove special handling for specific editor code
(`copy_or_reuse_particle_system`). This should never have been
accepted in ED code area, and is now handled by
`BKE_object_copy_modifier`.
* Factorize copying of the whole modifier stack into new
`BKE_object_modifier_stack_copy`, now used by both `object_copy_data`
and `BKE_object_link_modifiers`.
Note that this implies that `BKE_object_copy_modifier` and
`BKE_object_copy_gpencil_modifier` are now to be used exclusively to
copy single modifiers. Full modifier stack copy should always use
`BKE_object_modifier_stack_copy` instead.
Fix T82945: Crash when dragging modifiers in Outliner.
Maniphest Tasks: T82945
Differential Revision: https://developer.blender.org/D10148
Remove DNA headers, using forward declarations where possible.
Also removed duplicate header, header including it's self
and unnecessary inclusion of libc system headers from BKE header.
Corrects incorrect usage of contraction for 'it is', when possessive 'its' was required.
Differential Revision: https://developer.blender.org/D9250
Reviewed by Campbell Barton
Currently all force effectors can only act on cloth when the force is
perpendicular to the surface. This makes sense for wind, but not for
other forces; and the user may want even wind to have some friction.
This changes effector code to output two force vectors - although
you of course can pass the same pointer for both. The force is split
between the two outputs based on a new per-effector setting.
Differential Revision: https://developer.blender.org/D8017
Previously this would be enabled when threads were used, but threads are now
basically always in use so there is no point. Further, this is only needed for
guarded allocation with --debug-memory which is not performance critical.
In preparation of TBB we need to split the finalize function into reduce
and free. Reduce is used to combine results and free for freeing any
allocated memory.
The reduce function is called to join user data chunk into another, to reduce the
result to the original userdata_chunk memory. These functions should have no side
effects so that they can be run on any thread.
The free functions should free data created during execution (TaskParallelRangeFunc).
Original patch by Brecht van Lommel
{rB61f49db843cf5095203112226ae386f301be1e1a}.
Reviewed By: Brecht van Lommel, Bastien Montagne
Differential Revision: https://developer.blender.org/D7394
The `BKE_animsys.h` and `anim_sys.c` files already had a an "AnimData
API" section. The code in that section has now been split off, and
placed into `BKE_anim_data.h` and `anim_data.c`.
All files that used to include `BKE_animsys.h` have been adjusted to
only include the animation headers they need (sometimes none).
No functional changes.
While it might be handy to have type-less functionality which is
similar to how C++ math is implemented it can not be easily achieved
with just preprocessor in a way which does not have side-effects on
wrong usage.
There macros where often used on a non-trivial expression, and there
was at least one usage where it was causing an actual side effect/bug
on Windows (see change around square_f(sh[index++]) in studiolight.c).
For such cases it is handy to have a function which is guaranteed to
have zero side-effects. The motivation behind actually removing the
macros is that there is already a way to do similar calculation. Also,
not having such macros is a way to guarantee that its usage is not
changed in a way which have side-effects and that it's not used as an
inspiration for cases where it should not be used.
Differential Revision: https://developer.blender.org/D7051
- Use 'BKE_object_defgroup' prefix for object functions.
- Rename 'defvert_verify_index' to 'defvert_ensure_index'
since this adds the group if it isn't found.
A collection of smaller changes that are required in the /blender/source files. A lot of them are also due to variable renaming.
Reviewed By: sergey
Maniphest Tasks: T59995
Differential Revision: https://developer.blender.org/D3855
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
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
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.
For wome reason, tag to mark normals as needing recompute was commented
out instead of updated to new system, during conversion of DynaPaint
code for 2.8 new evaluation stack... Trivial fix.
Modifier previews should be implemented by a more generic system.
The current system is already a hack and needed a lot of work
to get it working again in 2.80 and even so that would be replaced by
another system in the near future.
For Vertex Colors we have a work around in place by using Workbench
Vertex Colors. For Vertex Weights we loose the previewing. Not sure
targetting weight is working (even for 279).
Reviewed By: brecht
Maniphest Tasks: T63857
Differential Revision: https://developer.blender.org/D4734
