| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
This patch enables TBB as the default task scheduler. TBB stands for Threading Building Blocks and is developed by Intel. The library contains several threading patters. This patch maps blenders BLI_task_* function to their counterpart. After this patch we can add more patterns. A promising one is TBB:graph that can be used for depsgraph, draw manager and compositor.
Performance changes depends on the actual hardware. It was tested on different hardwares from laptops to workstations and we didn't detected any downgrade of the performance.
* Linux Xeon E5-2699 v4 got FPS boost from 12 to 17 using Spring's 04_010_A.anim.blend.
* AMD Ryzen Threadripper 2990WX 32-Core Animation playback goes from 9.5-10.5 FPS to 13.0-14.0 FPS on Agent 327 , 10_03_B.anim.blend.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D7475
|
|
Reviewers: sergey
Differential Revision: https://developer.blender.org/D7559
|
|
|
|
|
|
Reviewers: sergey
Differential Revision: https://developer.blender.org/D7556
|
|
Reviewers: sergey
Differential Revision: https://developer.blender.org/D7553
|
|
Reviewers: sergey
Differential Revision: https://developer.blender.org/D7555
|
|
Reviewers: sergey, sybren
Differential Revision: https://developer.blender.org/D7521
|
|
Conflicts:
source/blender/blenkernel/intern/lib_query.c
source/blender/depsgraph/intern/builder/deg_builder_relations.cc
|
|
Fix T75279: BLI_assert failed when deleting object in debug build
(only).
And all general cases of ID pointer idproperties that would use a
data-block not referenced anywhere else in the depsgraph.
This includes idproperties from:
* All ID types;
* Bones and pose bones;
* Sequences;
* Nodes and sockets.
Differential Revision: https://developer.blender.org/D7551
|
|
Reviewers: sergey
Differential Revision: https://developer.blender.org/D7519
|
|
Reviewers: sergey
Differential Revision: https://developer.blender.org/D7512
|
|
|
|
This hides the original metaballs when they are used in
duplifaces/-verts instancing, and still shows the instanced metaballs.
The visibility of the original metaballs is now determined by the
visibility of the instancer. I'm not too thrilled about this, but at
least it gives users the ability to show/hide the metaballs for
viewport/render.
Differential Revision: https://developer.blender.org/D7478
|
|
Reviewers: sergey
Differential Revision: https://developer.blender.org/D7509
|
|
Reviewers: sergey
Differential Revision: https://developer.blender.org/D7506
|
|
|
|
|
|
|
|
Solve O(n^2) time complexity problem where a dependency graph iterator loops
over all nodes to clear flags, which happened for every object at the start
of transform.
Differential Revision: https://developer.blender.org/D7503
|
|
In preparation for {D7475}
|
|
issue: Painting a texture that is set as a particle system influencer, doesn't
update particles. An external trigger (such as changing influence slider)
is required to update particles.
fix: The root cause is a missing relationship from image to texture in the
dependency graph.
test: Once fixed, image texture painting updates expected dependencies
such as particle system influence or displacement modifier.
Reviewed By: sergey
Maniphest Tasks: T75845
Differential Revision: https://developer.blender.org/D7472
|
|
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
|
|
|
|
Scene audio volume changes require the scene to be tagged with
`ID_RECALC_AUDIO_VOLUME` (see `BKE_scene_update_sound()`). Tagging
happens in the RNA update function `rna_Scene_volume_update()`, but that
function is not called by the animation system. As a result, animated
volume changes are not sent to the audio system.
This commit adds a new depsgraph operation node that sets this tag when
necessary, so that the animated values are used in the rest of the
depsgraph evaluation.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D7429
|
|
|
|
|
|
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
|
|
|
|
as FakeIK for FK posing)
The issue was that the deps graph relation builder assumed that all
bones that had a IK constraint on them would be evaluated. However for
targetless IK bones, only the active bone would receive updates and the
others would be skipped (as those would be treated as if the IK
constraint was disabled).
I didn't see an easy way to solve this from the depsgraph side of
things.
Instead I came up with a solution that I feel is quite strait forward
and reflects what is actually supposed to happen under the hood.
Now all targetless IK constraints are treated as disabled and will not
be added to any relations in the depsgraph.
Instead, a temporary IK constraint will be created when the bone in
question is transformed. This is basically activating "Auto IK" for the
bone while transforming.
Reviewed By: Sergey, Brecht
Differential Revision: http://developer.blender.org/D7378
|
|
Tasks: move priority from task to task pool {rBf7c18df4f599fe39ffc914e645e504fcdbee8636}
Tasks: split task.c into task_pool.cc and task_iterator.c {rB4ada1d267749931ca934a74b14a82479bcaa92e0}
Differential Revision: https://developer.blender.org/D7385
|
|
Forgot to take into account legacy DEG_id_tag_update with zero flag.
|
|
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
|
|
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.
|
|
The files are now split up into the following sections:
- `BKE_anim_path.h` and `anim_path.c` for path/curve functions.
- `BKE_anim_visualization.h` and `anim_visualizationanim_path.c` for
animation visualization (mostly motion paths).
- `BKE_duplilist.h` for DupliList function declarations. These were
already implemented in `object_dupli.c`, so they were rather out of
place being declared in `BKE_anim.h` in the first place.
No functional changes.
|
|
This is a common, unambiguous abbreviation
already used throughout the code-base.
|
|
The root cause of the issue reported in T74983 is that an `IDNode` would
not be marked as user-modified. This marking happened while looping over
outgoing relations of one of its operation nodes. Since rBff60dd8b18ed
unused relations are removed, and as a result the `IDNode` would not be
marked.
The solution was to move the responsible code outside the loop; this is
probably a good idea anyway, as the code did not actually use the
looped-over relations at all, and was thus repeated unnecessarily.
|
|
Reviewers: brecht
Differential Revision: https://developer.blender.org/D7302
|
|
|
|
|
|
|
|
The looptri is repeated in the linked Meshes but the pointer
is only referenced in the evaluated ones.
This reverts commit 64982e213f014123d1b0406cf9ae893910a6a3d3.
|
|
More detailed symptoms: there was no curve cache created for an object
which was used by draw manager.
A bit tricky situation, which involves collection instances and their
proxies.
The root of the problem in the dependency graph was that instanced
collections visibility was not updated when object is requested with
different visibility. So what was happening is that one of the objects
was pulled as an indirect dependency of something invisible, so it
built instanced collections as if the instancer is invisible. After
that the same object was built as visible. Before this fix this was
only update object flags, the instanced collections still believed they
are invisible. Since there is no path via relations which would connect
visible object with instanced objects the visibility flush which is
happening during graph finalization did not "fix" the visibility flags.
This change makes it so instanced collections are updating their
visibility when their instancer's visibility is changing to truth.
This is similar to how collections will accumulate their visibility
when same collection is used from multiple ones with different
visibility.
However, this alone wasn't enough to get crash fixed. This marked
collections as visible, but the geometry component of the curve object
was still considering self as invisible.
This is something tricky, since the code which is responsible for this
issue was added as an optimization in afb4da6650d. This looks like like
an oversight in that commit since it's rather weird that ID node's
flag would depend on construction order (in "normal" object builder the
ID node's directly_visible flag is initialized to object's visibility).
So it seems logical to get this part of code in sync between "regular"
and "accumulative" object builder.
And last but not least the naming is_directly_visible is old and does
not really represent what it actually mans now: a more correct name
would be "will be used by the draw manager".
Differential Revision: https://developer.blender.org/D7217
|
|
The `build_driver_relations()` function in the depsgraph relations builder
adds relations between drivers that potentially write to the same memory
location. This of course is only useful when there are two or more drivers.
|
|
My previous fix (rB4c30dc343165) worked, except for an off-by-one error.
|
|
No functional changes.
Differential Revision: https://developer.blender.org/D7173
|
|
Started to happen after recent fix for T72632.
Was caused by runtime fields backup doing an early exit in the case the
given ID was never expanded by the Copy-on-Write mechanism, but it was
not done int the backup restore function (since it was not possible to
know "locally").
Now both init() and restore() will do an early exit when the ID had
nothing to be backed up.
|
|
|
|
Mpving utils from idcode to idtype proved to be somewhat painful for
some reasons, but now all looks good.
Had to add a fake/empty shell for the special snowflake too,
`ID_LINK_PLACEHOLDER/INDEX_ID_NULL`...
|
