This also renames `MutableArrayRef` to `MutableSpan`.
The name "Span" works better, because `std::span` will provide
similar functionality in C++20. Furthermore, a shorter, more
concise name for a common data structure is nice.
The main focus here was to improve the docs significantly. Furthermore,
I reimplemented `Set`, `Map` and `VectorSet`. They are now (usually)
faster, simpler and more customizable. I also rewrote `Stack` to make
it more efficient by avoiding unnecessary copies.
Thanks to everyone who helped with constructive feedback.
Approved by brecht and sybren.
Differential Revision: https://developer.blender.org/D7931
This adds a new `CPPType` that encapsulates information about how to handle
instances of a specific data type. This is necessary for the function evaluation
system, which will be used to evaluate most of the particle node trees.
Furthermore, this adds an `IndexMask` class which offers a surprisingly useful
abstraction over an array containing unsigned integers. It makes two assumptions
about the underlying integer array:
* The integers are in ascending order.
* There are no duplicates.
`IndexMask` will be used to "select" certain particles that will be
processed in a data-oriented way. Sometimes, operations don't have to
be applied to all particles, but only some, those that are in the indexed by
the `IndexMask`. The two limitations imposed by an `IndexMask` allow for
better performance.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D7957
This was caused by a side-effect of our exporting code's memory
management (Alembic considers data "written" and "final" when its C++
objects go out of scope) in combination with my change in
rB65574463fa2d. I removed an "only export UVs on the first frame" clause
because it was unclear why this restriction was there. As it turns out,
it breaks the export of the 2nd and subsequent UV maps on an animated
mesh. Effectively, on every frame the Alembic library thought we want to
create a new UV map, instead of continuing to write a new frame of data
to the existing one.
This is resolved by keeping a reference to the C++ objects for the UV
maps in memory while the exporter is running.
When the Child Of constraint is owned by a bone, before the constraint is
run the matrix is converted from world to pose space. However, setting the
inverse should also take the armature object's transform into account.
Add TBB::flow graph scheduling to BLI_task.
Using flow graphs, a graph of nodes (tasks) and links can be defined.
Work can flow though the graph. During this process the execution of the nodes will be
scheduled among the available threads.
We are planning to use this to improve the threading in the draw manager.
The implemented API is still limited it only supports sequential flows. Joins and buffers
are not supported. We could eventually support them as part of an CPP API. These features
from uses compile time templates and are hard to make a clean C-API for this.
Reviewed By: Sergey Sharybin, Brecht van Lommel
Differential Revision: https://developer.blender.org/D7578
The long-term goal is to move code out of `abc_util.{h,cc}` into either
files with better, more concrete names, or simply into the one file
where they are used.
No functional changes.
Unfortunately there is no `EXPECT_NOT_LT`; as the `HierarchyContext` only
has an `operator<()` function, testing for `(A < B) == false` is different
than simply testing `(A >= B)`.
No functional changes.
This introduces unittests for FCurve evaluation.
No functional changes to actual Blender code.
Differential Revision: https://developer.blender.org/D6778
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
Blender was not configured to exit with non-zero return code on Python errors.
A bunch of tests worked around this but not all. This removes the need for such
workarounds.
This uses the same framework as automated modifier tests. It adds a physics
modifier, bakes and compares vertex coordinates on the end frame.
Differential Revision: https://developer.blender.org/D7017
Submitting on behalf of Jesse Y (deadpin).
In test harness for modifier testing, now run mesh validation
on output mesh. Also, fix printing so it interleaves properly.
CentOS on the buildbot still runs Python 3.6, which is also used for the
unit tests. This means that the tests can't use language features that
are available to Blender itself. And testing with a different version of
Python than will be used by the actual code seems like a bad idea to me.
This commit adds `TEST_PYTHON_EXECUTABLE` as advanced CMake option. This
will allow us to set a specific Python executable when we need it. When
not set, a platform-specific default will be used:
- On Windows, the `python….exe` from the installation directory. This is
just like before this patch, except that this patch adds the
overridability.
- On macOS/Linux, the `${PYTHON_EXECUTABLE}` as found by CMake.
Every platform should now have a value (configured by the user or
detected by CMake) for `TEST_PYTHON_EXE`, so there is no need to allow
running without. This also removes the need to have some Python files
marked as executable.
If `TEST_PYTHON_EXE` is not user-configured, and thus the above default
is used, a status message is logged by CMake. I've seen this a lot in
other projects, and I like that it shows which values are auto-detected.
However, it's not common in Blender, so if we want we can either remove
it now, or remove it after the buildbot has been set up correctly.
Differential Revision: https://developer.blender.org/D7395
Reviewed by: campbellbarton, mont29, sergey
* Rename template parameter N to InlineBufferCapacity
* Expose InlineBufferCapacity parameter for Set and Map
* Add some comments
* Fixed an error that I introduced recently
This is not currently used and will take some work to support with TBB, so
remove it until we have a new implementation based on TBB.
Fixes T76005, parallel range pool tests failing.
Ref D7475
Instead of building on top of `BLI::Vector`, just use a raw array
and handle the growing in `BLI::VectorSet`.
After this change, the existing `EdgeSet` can be reimplemented using
`BLI::VectorSet` without performance regressions.
This was used to investigate T73840. Since the armature math is far from
simple, I thought it would be a good idea to start writing some unit
tests for it.
No functional changes in Blender itself.
