| Age | Commit message (Collapse) | Author |
|---|
|
Use C comments for plain text.
|
|
This reverts commits
bfa3dc91b75407b063f2ac991b176d98c050f92d,
52b94049f2a71a74f52247f83657cf3a5c8712b4,
ae379714e4f1eca74f5f77532a6e959f29445236,
a770faa811ee62837eb540b0bd83ca0770f16663,
4ed029fc02b022cb5ff28ed3ce70992c450d2be5,
101a493ab556c6597ac91fba204059be67b35990 and
62a2faa7ef39130446716d7a06215cd1df1eb2ac.
And fixes T89955.
Changing the dependency graph is a can of worms and the result is
a kind of unpredictable.
A different solution will be planned.
|
|
Update was skipping the batch cache.
|
|
Regression introduced in {rBbfa3dc91b754}.
`ID_RECALC_GEOMETRY` should tag all operations of the `GEOMETRY`
component and not just the operation of node `GEOMETRY_EVAL_INIT`.
|
|
`POINT_CACHE_RESET` pointed to `GEOMETRY_EVAL_INIT` while
`GEOMETRY_EVAL_INIT` pointed to `POINT_CACHE_RESET`.
Now `POINT_CACHE_RESET` points to the same nodes pointed to by
`GEOMETRY_EVAL_INIT` thus avoiding the dependency cycle.
|
|
|
|
This shows the text as part of the assertion message.
|
|
Differential Revision: https://developer.blender.org/D11851
|
|
During a mesh transformation in edit mode (Move, Rotate...), only part of
the batch cache needs to be updated.
This commit allows only update only the drawn batches seen in
`BKE_object_data_eval_batch_cache_deform_tag` if the new
`ID_RECALC_GEOMETRY_DEFORM` flag is used.
This new flag is used in the transforms operation for edit-mesh and
results in 1.6x overall speedup in heavy subdiv cube.
Differential Revision: https://developer.blender.org/D11599
|
|
In this bug report it resulted in rendering animations stopping too early,
but this affected more areas.
After the previous cleanup commit, it becomes clear that frame and ctime
values were mixed up.
|
|
Confusingly, BKE_scene_frame_get did not match the frame number as expected by
BKE_scene_frame_set. Instead it return the value after time remapping, which
is commonly named "ctime".
* Rename BKE_scene_frame_get to BKE_scene_ctime_get
* Add a new BKE_scene_frame_get that matches BKE_scene_frame_set
* Use int/float depending if fractional frame is expected
|
|
The geometry nodes modifier uses id properties for the inputs to node groups.
That is because the set of properties changes depending on which geometry
node group is selected.
The animation was not updated correctly because the `ANIMATION_EVAL`
depsgraph node was not evaluated, because nothing depended on it in the
depsgraph. This patch makes sure that the proper link to the geometry
component is inserted.
Differential Revision: https://developer.blender.org/D11831
|
|
|
|
|
|
Also use doxy style function reference `#` prefix chars when
referencing identifiers.
|
|
|
|
This worked for existing scenes but adding new objects was asserting
needs further investigation.
|
|
This resolves a bottleneck where every update while transforming
copied the entire mesh data-block, which isn't needed as the edit-mesh
is the source of the data being edited.
Testing shows a significant overall speedup when transforming:
- ~1.5x with a subdivided cube 1.5 million vertices.
- ~3.0x with the spring mesh (edit-mode with modifiers disabled,
duplicated 10x to drop performance).
Reviewed By: sergey
Ref D11337
|
|
Avoid computationally expensive copying operations
when only some settings have been modified.
This is done by adding support for updating parameters
without tagging for copy-on-write.
Currently only mesh data blocks are supported,
other data-blocks can be added individually.
This prepares for changing values such as edit-mesh auto-smooth angle
in edit-mode without duplicating all mesh-data.
The benefit will only be seen when the user interface no longer tags
all ID's for copy on write updates.
ID_RECALC_GEOMETRY_ALL_MODES has been added to support situations
where non edit-mode geometry is modified in edit-mode.
While this isn't something user are likely to do,
Python scripts may change the underlying mesh.
Reviewed By: sergey
Ref D11377
|
|
Without this tests fail to lknk in D11377. Commit separately as the
depsgraph is using BKE it should link to it.
|
|
|
|
Would crash when adding or removing a collection directly to the master
collection of a scene.
Consequence of change to handle depsgraph-controlled evaluation of some
IDs (like excluded collections which do not get evaluated and do not get
a COW anymore). See rBcf4258673755 and D10907.
Note that this mostly demonstrates once again how weak and flacky our
handling of embedded IDs still remains, with some part of the code
handling them as independent IDs, some as fully local/private data, some
as a mix of both... and lots and lots of custom handling code and corner
cases that are a bottomless pit of issues.
Also quiet incredible that this was not reported already, luckily this
original change did not make it to 2.93 release.
|
|
Delay depsgraph visibility update tagging until it is known that
graph relations are up to date, and until it is known that the graph
is actually needed to be evaluated.
Differential Revision: https://developer.blender.org/D11660
|
|
No functional changes. Just makes it clear this is not an immediate
update, and will make an upcoming change more localized.
|
|
In addition to the base bone transformation itself, B-Bones have
controls that affect transformation of its segments. For rotation
the features are quite complete, allowing to both reorient the
Bezier handles via properties, and to control them using custom
handle bones. However for scaling there are two deficiencies.
First, there are only X and Y scale factors (actually X and Z),
while lengthwise all segments have the same scaling. The ease
option merely affects the shape of the curve, and does not cause
actual scaling.
Second, scaling can only be controlled via properties, thus
requiring up to 6 drivers per joint between B-Bones to transfer
scaling factors from the handle bone. This is very inefficient.
Finally, the Z channels are confusingly called Y.
This commit adds a B-Bone Y Scale channel and extra B-Bone flag
fields to DNA with appropriate versioning (including for F-Curves
and drivers) in preparation to addressing these limitations.
Functionality is not changed, so the new fields are not used
until the following commits.
Differential Revision: https://developer.blender.org/D9870
|
|
After looking into task isolation issues with Sergey, we couldn't find the
reason behind the deadlocks that we are getting in T87938 and a Sprite Fright
file involving motion blur renders.
There is no apparent place where we adding or waiting on tasks in a task group
from different isolation regions, which is what is known to cause problems. Yet
it still hangs. Either we do not understand some limitation of TBB isolation,
or there is a bug in TBB, but we could not figure it out.
Instead the idea is to use isolation only where we know we need it: when
holding a mutex lock and then doing some multithreaded operation within that
locked region. Three places where we do this now:
* Generated images
* Cached BVH tree building
* OpenVDB lazy grid loading
Compared to the more automatic approach previously used, there is the downside
that it is easy to miss places where we need isolation. Yet doing it more
automatically is also causing unexpected issue and bugs that we found no
solution for, so this seems better.
Patch implemented by Sergey and me.
Differential Revision: https://developer.blender.org/D11603
|
|
These were limited to obvious cases. Some less obvious cases
were kept as refactoring might make them necessary in future.
|
|
|
|
Under some circumstances using task isolation can cause deadlocks.
Previously, our task pool implementation would run all tasks in an
isolated region. Now using task isolation is optional and can be
turned on/off for individual task pools.
Task pools that spawn new tasks recursively should never enable
task isolation. There is a new check that finds these cases at runtime.
Right now this check is disabled, so that this commit is a pure refactor.
It will be enabled in an upcoming commit.
This fixes T88598.
Differential Revision: https://developer.blender.org/D11415
|
|
This patch adds relatively small changes to the curve draw
cache implementation in order to draw the curve data in the
viewport. The dependency graph iterator is also modified
so that it iterates over the curve geometry component, which
is presented to users as `Curve` data with a pointer to the
`CurveEval`
The idea with the spline data type in geometry nodes is that
curve data itself is only the control points, and any evaluated
data with faces is a mesh. That is mostly expected elsewhere in
Blender anyway. This means it's only necessary to implement
wire edge drawing of `CurveEval` data.
Adding a `CurveEval` pointer to `Curve` is in line with changes
I'd like to make in the future like using `CurveEval` in more places
such as edit mode.
An alternate solution involves converting the curve wire data
to a mesh, however, that requires copying all of the data, and
since avoiding it is rather simple and is in-line with future plans
anyway, I think doing it this way is better.
Differential Revision: https://developer.blender.org/D11351
|
|
|
|
This issue was that `BKE_object_eval_uber_data` was not called for
the text object, because its geometry was not dependent upon
and its `is_directly_visible` tag was `false`. The crash happens in
rendering code, because the evaluated data is missing.
This not only affects text objects, but all object types that have a
geometry component that geometry nodes does not support yet.
The solution is to just add the missing dependencies.
Differential Revision: https://developer.blender.org/D11385
|
|
|
|
|
|
disabled subcollections
Root of the issue was actually hidden deep in depsgraph itself: it would
not properly update all of its COW IDs using a datablock when depsgraph
decides to evaluate or un-evaluate it.
This would lead to evaluated IDs pointing to either:
- orig IDs when there was an evaluated version of those (annoying bug,
but not a crashing one).
- old address of previously evaluated IDs that no longer exists in the
depsgraph (causing the crash from the report e.g.).
This commit adds an extra step at the end of nodes building, that goes
over all of already existing IDs in the depsgraph to check whether they
do one of the two things above, and tag them for COW update if so.
NOTE: This only affects depsgraph (re-)building, not its evaluation.
This remains consistent with the fact that operations that may change
the depsgraph content (like Collection exclusion etc.) need to trigger a
rebuild.
NOTE: Performances: Worst case scenarii, like (un-)excluding a whole
character collection in a production file, lead to 5% to 10% extra
processing time in depsgraph building. Most of it comming from extra COW
processing (in depsgraph's update in `build_step_finalize`), the detection
loop itself only accounts for 1% to 2% of the whole building time.
Maniphest Tasks: T85752
Differential Revision: https://developer.blender.org/D10907
|
|
Share the pointer with the original mesh instead, this matches behavior
of all other objects edit-mode data.
Duplicating the edit-mesh pointer makes updates to edit-mesh require
a COPY_ON_WRITE update, which is currently an expensive operation
(copying the entire mesh).
Notes:
- This change is from 802027f3f8f9a83a77134a2b104a25ff3a4ac013
so the edit-meshes object pointer `BMEditMesh.ob` referenced the COW
version of the object. This pointer has since been removed, so the
copy is no longer needed.
- Having a separate edit-mesh pointer could be used so linked duplicates
could have their own generated meshes. For this to be supported,
many other changes would be needed: see D10920.
|
|
|
|
Resolve ownership ambiguity with shared physics pointers.
Previously, LIB_ID_CREATE_NO_MAIN allowed pointer sharing with
the source ID so physics caches can be shared between original and
evaluated data: (Object.soft.shared & Object.rigidbody_object.shared).
This only worked properly for LIB_TAG_COPIED_ON_WRITE ID's,
as LIB_TAG_NO_MAIN can be used in situations where the original ID's
lifetime limited by it's original data.
This commit adds `LIB_ID_COPY_SET_COPIED_ON_WRITE` so ID's only share
memory with original data for ID's evaluated in the depsgraph.
For all other uses, a full copy of physics data is made.
Ref D11228#287094
|
|
The sockets are not exposed in any nodes yet.
They work similar to the Object/Collection sockets, which also
just reference a data block.
This is part of D11222.
|
|
Use the term `ensure` since it makes it clear the data is
not manipulated if it already exists.
|
|
Issue was caused by anim handle being reset by
`DEG_evaluate_on_framechange()`
Preserve anim handle by backing it up in
`blender::deg::SequenceBackup`
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D11059
|
|
This was a mistake in rBb67fe05d4bea2d3c9efbd127e9d9dc3a897e89e6.
|
|
This fixes T87666 and T83252.
The boolean modifier and geometry nodes can depend on the geometry
of an entire collection. Before, the modifiers had to manually create relations
to all the objects in the collection. This worked for the most part, but was
cumbersome and did not solve all issues. For example, the modifiers were not
properly updated when objects were added/removed from the referenced collection.
This commit introduces the concept of "collection geometry" in the depsgraph.
The geometry of a collection depends on the transforms and geometry of all
the objects in it. The boolean modifier and geometry nodes can now just depend
on the collection geometry instead of creating all the dependencies themselves.
Differential Revision: https://developer.blender.org/D11053
|
|
|
|
As Python can access COW ID's, ensure it's instance is kept on update.
This could happen when the "Use Self" argument was enabled for a driver.
|
|
We weren't clearing the recalc flags for that case.
|
|
Some persistent data code was disable due to a deeper design issue, which
meant some updates were not communicated to renderers.
Dependency graph updates work in two passes, once where Blender scene
animation updates are done, then app handler scripts can run to make further
scene modifications, and then the depsgraph is updated again to take those
into account.
Previously the viewport would update renderers twice when such app handler
scripts were present. Now both viewport and persistent data rendering update
the renderers only once, accumulating updates from both passes.
|
|
Fix `nullptr` redeference when setting 'orig_data' pointers on CoW copies,
by stopping the loop also when `element_cow == nullptr`. This avoids a
crash of Blender when the original list of pointers is longer than the
CoW list of pointers.
I've also added a `BLI_assert()` that checks for equal lengths of the
two `ListBase`s, so that problems like these aren't hidden away completely.
The root cause of the crash was actually a modifier that was assigned to
an object of the wrong type (an Armature object doesn't support modifiers).
This caused the list of modifiers on the CoW copy to be shorter than the
list of modifiers on the original Object. It's still a mystery how that
object got that modifier in the first place.
|
|
|
|
This removes a lot of unnecessary code that is generated by
the compiler automatically.
In very few cases, a defaulted destructor in a .cc file is
still necessary, because of forward declarations in the header.
I removed some defaulted virtual destructors, because they are not
necessary, when the parent class has a virtual destructor already.
Defaulted constructors are only necessary when there is another
constructor, but the class should still be default constructible.
Differential Revision: https://developer.blender.org/D10911
|
