| Age | Commit message (Collapse) | Author |
|---|
|
This change makes it so that objects which are temporary hidden from
the viewport (the icon toggle in outliner) do not affect on the
performance of the viewport.
The attached file demonstrates the issue. Before this change hiding
the object does not change FPS, after this change FPS goes high when
the object is hidden.
F13435936
Changing the object temporary visibility is already expected to tag
scene for bases updates, which flushes down the stream to the object
visibility update. So the only remaining topic was to ensure the
graph does a special round of visibility update on such changes.
Differential Revision: https://developer.blender.org/D15813
|
|
While it is hard to measure the performance impact accurately, there
is no need to perform per-modifier string lookup on every frame update.
Implemented as an exceptional case in the code which flushes updates to
the entire component. Sounds a bit suboptimal, but there are already
other exception cases handled in the function.
Differential Revision: https://developer.blender.org/D15812
|
|
While missing the break before a default that only breaks isn't
an error, it means adding new cases needs to remember to add the
break for an existing case, changing the default case will also
result in an unintended fall-through.
Also avoid `default:;` and add an explicit break.
|
|
Also remove two DispList references I missed in the previous commit.
|
|
|
|
With the ultimate goal of simplifying drawing and evaluation,
this patch makes the following changes and removes code:
- Use `Mesh` instead of `DispList` for evaluated basis metaballs.
- Remove all `DispList` drawing code, which is now unused.
- Simplify code that converts evaluated metaballs to meshes.
- Store the evaluated mesh in the evaluated geometry set.
This has the following indirect benefits:
- Evaluated meshes from metaball objects can be used in geometry nodes.
- Renderers can ignore evaluated metaball objects completely
- Cycles rendering no longer has to convert to mesh from `DispList`.
- We get closer to removing `DispList` completely.
- Optimizations to mesh rendering will also apply to metaball objects.
The vertex normals on the evaluated mesh are technically invalid;
the regular calculation wouldn't reproduce them. Metaball objects
don't support modifiers though, so it shouldn't be a problem.
Eventually we can support per-vertex custom normals (T93551).
Differential Revision: https://developer.blender.org/D14593
|
|
Need to update relations when modifiers are added or removed
since those create nodes in the dependency graph.
Added an assert statement to point at possible culprit so
that issues can be fixed more quickly.
|
|
|
|
Solves long-standing issue when dependencies of disabled modifiers are
evaluated.
Simple test case: no drivers or animation. Manually enabling modifier
is expected to bring FPS up, enabling modifier will bring FPS (sine
evaluation can not be avoided)
F13336690
More complex test case: modifier visibility is driven by an animated
property. In am ideal world FPS during property being zero is fast
and when property is 1 the FPS is low.
F13336691.
Differential Revision: https://developer.blender.org/D15625
|
|
No functional changes expected.
|
|
|
|
|
|
|
|
|
|
The name was confusing to a level that it sounded like the relation
goes the opposite direction than it is intended.
|
|
The build_object_data_geometry() is never called on armatures.
|
|
|
|
Happens after recent changes in the area.
The asserts were a bit too strict and were against the way how the
ID_RECALC_ALL is handled. So remove them with explanation why things
needs to be silent.
|
|
The tagging code was iterating over bits set in the ID_RECALC_ALL and
was casting the flag to IDRecalcFlag. This was triggering an undefined
behavior warning in Clang since the bit might not have a corresponding
value in the enumerator.
The solution is to pre-define all reacalc flags for all bits. While
this seems a bit annoying this seems to be the least fragile solution
from all suggested ones.
Differential Revision: https://developer.blender.org/D15602
|
|
Always use unsigned int for the recalc flags. This allows to use
all 32 bit of integer for the flags without worrying about the
sign. Use full notation of `unsigned int` instead of short `uint`
to avoid pulling more headers in.
Whenever depsgraph API allows passing combined recalc flags call
the variable `flags` and use `unsigned int` type for it. For a
single flag use `IDRecalcFlag` flag.
No functional changes expected.
|
|
Adds `rna_path.cc` and `RNA_path.h`.
`rna_access.c` is a quite big file, which makes it rather hard and
inconvenient to navigate. RNA path functions form a nicely coherent unit
that can stand well on it's own, so it makes sense to split them off to
mitigate the problem. Moreover, I was looking into refactoring the quite
convoluted/overloaded `rna_path_parse()`, and found that some C++
features may help greatly with that. So having that code compile in C++
would be helpful to attempt that.
Differential Revision: https://developer.blender.org/D15540
Reviewed by: Brecht Van Lommel, Campbell Barton, Bastien Montagne
|
|
A mistake in the 0dcee6a3866 which made specific driven visibility
to work, but did not properly handle actual time-based visibility.
The basic idea of the change is to preserve recalculation flags of
nodes which were tagged for update but were not evaluated due to
visibility constraints. In the file from the report this makes it
so tagging which is done first time ID is in the dependency graph
are handled when the ID actually becomes visible. This is what
solved the root of the problem from the report: there was missing
geometry update since it was "swallowed" by the evaluation during
the object being invisible. In other configurations this change
allows to handle pending geometry updates due to animated modifiers
be handled when object becomes visible without time change.
This change also solves visibility issue of the synchronization
component which also started to be handled badly since the
previous fix attempt. Basically, the needed exception in its
visibility handling did not happen and a regular logic was used
for it.
Tested with files from the T99733, T99976, and from the Heist
project.
Differential Revision: https://developer.blender.org/D15544
|
|
|
|
|
|
|
|
Differential Revision: https://developer.blender.org/D15510
|
|
The issue was caused by the fact that objects with driven or animated
visibility were considered visible by the dependency graph evaluation.
This change makes it so the dependency graph evaluation is aware of
visibility which might be changing. This is achieved by evaluating the
path of the graph which affects objects visibility and adjusts to it
before evaluating the rest of the graph.
There is some time penalty to this, but there does not seem to be a
way to fully avoid this penalty.
With the production shot from the heist project the FPS drops by a
tenth of a frame (~9.4 vs ~9.3 fps) when adding a driver to an object
which keeps it visible. Note that this is a bit hard to measure since
the FPS fluctuates quite a bit throughout the playback. On the other
hand, having a driver on a visibility of a heavy object from character
and setting visibility to false gives big speedup.
Also worth noting that there is no penalty at all when there are no
animated visibilities in the scene.
Differential Revision: https://developer.blender.org/D15498
|
|
The goal is to make it possible to evaluate the graph in multiple
passes without evaluating the same node multiple times.
Currently should not be any functional changes.
|
|
Semantically it is more correct as the cache does not modify the ID.
There is need to do couple of const casts since the BKE (which is in C)
does not easily allow to iterate into f-curves of const ID.
Should be no functional changes.
|
|
|
|
Disambiguate from nodes visibility flags.
|
|
|
|
Move it from generic visibility handling to the synchronization
component node implementation. Should be no functional changes.
|
|
Should make it easier to read. No functional changes expected.
|
|
No functional changes, just makes code more semantically clear.
|
|
|
|
Should be no functional changes.
|
|
|
|
Matches the builder API, making some code less verbose.
|
|
|
|
Not sure why multiple pools were created: the pool should be able to
handle two sets of tasks.
Perhaps non-measurable improvement in terms of performance but this
change simplifies code a bit.
|
|
This is useful when using an armature as a camera rig, to avoid creating and
targetting an empty object.
Differential Revision: https://developer.blender.org/D7012
|
|
Even if the driver is not dependent on time the modifiers were always
re-evaluated during playback. This is due to the legacy nature of the
check whether modifier depends on time or not: it was simply checking
for sub-string match for modifier in the F-Curve and drivers RNA paths.
Nowadays such dependencies are created by the dependency graph builder,
which allows to have more granular control over what depends on what.
The code is now simplified to only check for "static" dependency of the
modifier form time: for example, Wave modifier which always depends on
time (even without explicit animation involved).
This change also fixes missing relation from the animation component to
the shader_fx modifiers, fixing race condition.
Additional files used to verify relations:
- Geometry: F13257368
- Grease Pencil: F13257369
- Shader FX: F13257370
In these files different types of modifiers have an animated property,
and the purpose of the test is to verify that the modifiers do react
to the animation and that there is a relation between animation and
geometry components of the object. The latter one can only be checked
using the dependency graph relation visualization.
The drivers are not tested by these files. Those are not typically
depend on time, and if there were missing relation from driver to
the modifier we'd receive a bug report already. As well as if there
was a bug in missing time relation to a driver we'd also receive a
report.
Differential Revision: https://developer.blender.org/D15358
|
|
|
|
|
|
Active camera is a property of Scene, so need to take scene changes into
account for such drivers to work reliably.
The fix covers all the common cases of such configurations, but some of
them might not be yet fully supported. Mainly cases when the target ID
is not covered by the copy-on-write mechanism.
There is a fuller explanation available in the code for the ease of reading
by the future generations.
Differential Revision: https://developer.blender.org/D15146
|
|
Instead of directly accessing constraint-specific callbacks
in code all over blender, introduce two wrappers to retrieve
and free the target list.
This incidentally revealed a place within the Collada exporter
in BCAnimationSampler.cpp that didn't clean up after retrieving
the targets, resulting in a small memory leak. Fixing this should
be the only functional change in this commit.
This was split off from D9732.
Differential Revision: https://developer.blender.org/D13844
|
|
|
|
Mostly duplicate includes, also use nullptr, and using default
member initializers.
|
|
`bNodeTree` has a lot of run-time embedded in it currently. Having a separately
allocated run-time struct has some benefits:
* Run-time data is not stored in files.
* Makes it easy to use c++ types as run-time data.
* More clear distinction between what data only exists at run-time and which doesn't.
This commit doesn't move all run-time data to the new struct yet, only the data where
I know for sure how it is used. The remaining data can be moved separately.
Differential Revision: https://developer.blender.org/D15033
|
