| Age | Commit message (Collapse) | Author |
|---|
|
Most of this code is covered by unit tests.
|
|
This commit only moves code into the `blender::io::alembic` namespace,
it does not move `static` functions into an anonymous namespace.
No functional changes.
|
|
This moves most of the exporter-related code
from `source/blender/io/alembic/intern`
to `source/blender/io/alembic/exporter`
This is to prepare the Alembic code for the switchover to using
`blender::io::AbstractHierarchyIterator`. When that happens, a few more
files will be added, and having things in a separate 'exporter'
directory makes things less cluttered.
Note that exporting consists of multiple steps (determine export
hierarchy, create Alembic archive, and then write data into it), which
is why the directory is called "exporter", but many of the files are
called "writer".
No functional changes.
|
|
This isn't really in C++ standard, some corner cases work in some
compilers (like when all fields are specified), but in general they
do not work.
For some reason MSVC builder started to complain about it now,
weird but better not rely on compiler specifics.
|
|
Are reported by MSVC 2019 after C++17 switch.
One might suggest lets just silence the warning, I will say why to have
specific signed/unsigned types in API just to then (usafely) ignore the
sign conversion.
|
|
random_shuffle was removed (at least the used version).
|
|
Blender now always exports transforms as as "inheriting", as Blender has
no concept of parenting without inheriting the transform.
Previously only objects with an actual parent were marked as
"inheriting", and parentless objects as "non-inheriting". However,
certain packages (for example USD's Alembic plugin) are incompatible
with non-inheriting transforms and will completely ignore such
transforms, placing all such objects at the world origin.
When importing non-inheriting transforms from Alembic, Blender will
break the parent-child relation and thus force the child to (correctly)
interpret the transform as world matrix.
|
|
Other types already had spaces, periods, and colons replaced by
underscores. The upcoming Alembic exporter (based on the
`AbstractHierarcyIterator` class) will be more consistent and apply the
same naming rules everywhere. This is in preparation for that change.
The `get_…_name()` functions in `abc_util.{cc,h}` will be removed then.
|
|
Previously the Alembic exporter exported a mesh object to
`{object.name}/{object.name}Shape`. Now it exports to
`{object.name}/{mesh.name}` instead. The same change also applies to
other object data types.
Note that the code now is a bit hackish, as `m_name` is set even in
cases where it isn't used. This hackishness was already there, though,
but it's now just more visible. This will all be cleaned up when the
Alembic exporter is ported to use the `AbstractHierarchyImporter`
structure of the Universal Scene Description (USD) exporter.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D7672
|
|
This is in order to prepare for compatibility with the Alembic exporter.
That exporter is capable of writing object transforms and object data at
different (sub)frames.
The rename from `created_writers` to `used_writers` is necessary, as not
all created writers will be actually used in each iteration.
The Universal Scene Description (USD) exporter does not make use of
this.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D7670
|
|
The goal of the `AbstractHierarchyIterator` class (and supporting
classes) was to use it in different exporters. It shouldn't be part of
the USD module + namespace any more, now that it will also be used in
the upcoming Alembic exporter rewrite.
The source files are moved into `io/common`, which is compiled & linked
into a new library `bf_io_common`. The unittests are still inside the
`tests/gtests/usd` directory. They should be moved to a separate test
module too, but that will be delayed until after T73268 has been
resolved.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D7669
|
|
The matrix interpolation function `interp_m3_m3m3()` decomposes the
matrices into rotation and scale matrices, converts the rotation
matrices to quaternions, SLERPs the quaternions, and converts the result
back to a matrix. Since quaternions cannot represent axis flips, this
results in interpolation problems like described in T77154.
Our interpolation function is based on "Matrix Animation and Polar
Decomposition", by Ken Shoemake & Tom Duff. The paper states that it
produces invalid results when there is an axis flip in the rotation
matrix (or negative determinant, or negative scale, those all indicate
the same thing). Their solution is to multiply the rotation matrix with
`-I`, where `I` is the identity matrix. This is the same as element-wise
multiplication with `-1.0f`. My proposed solution is to not only do that
with the rotation matrix `R`, but also with the scale matrix `S`. This
ensures that the decomposition of `A = R * S` remains valid, while also
making it possible to conver the rotation component to a quaternion.
There is still an issue when interpolating between matrices with
different determinant. As the determinant represents the change in
volume when that matrix is applied to an object, interpolating between a
negative and a positive matrix will have to go through a zero
determinant. In this case the volume collapses to zero. I don't see this
as a big issue, though, as without this patch Blender would also produce
invalid results anyway.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8048
|
|
The interpolation of 4x4 and 3x3 matrices will fail when the rotation
component has a singularity, i.e. when there is one axis mirrored. Two
mirrored axes are just a rotation of 180 degrees around the third, and
three mirrored axes are such a rotation + a single axis mirror. To
prepare for a fix, I first wanted to cover the basic functionality with
a few unit tests.
These tests check that `interpolate(A, B, alpha)` always returns `A` for
`alpha=0`, always return `B` for `alpha=1`, and something in between for
`alpha=0.5`.
|
|
Main change from user side, besides that all pointers should now be
properly remapped to new IDs, is that linked objects are no longer
preserved when doing a full copy of scenes.
Will open a task to check whether we actually still want that behavior
(and re-code it in a more correct way then).
This is the main part of work done here, it aims at uniformizing and
sanitizing that 'deep copy' process for supported IDs (currently scenes,
collections and objects).
Note that there will be more follow up commits after that one, but this
should be the most risky and changing one.
|
|
This adds the `MultiFunction` type and some smallish utility types that it uses.
A `MultiFunction` encapsulates a function that is optimized for throughput by
always processing many elements at once.
This is an important part of the new particle system, because it allows us to
execute user generated node trees for many particles efficiently.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D8030
|
|
|
|
Similar to previous commit, aims to resolve compilation on
devtoolset-6.
|
|
Smells like GCC bug [1], which is backed up by the fact that locally
GCC-10 and CLang-10 works fine.
Since the change is trivial (and, arguably, correct since there is
no real difference between tests code and actual code) seems fine to
fix.
Fix suggested by Jacques Lucke, thanks!
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56480
|
|
|
|
This makes it easier to write range-for loops over all items
in the map without using auto.
|
|
There is a nice use case for this in depsgraph code.
Also I added some previously missing calls to std::move.
|
|
|
|
This is related to T76659.
This just renames data type names to `CD_PROP_STRING`, `CD_PROP_FLOAT`
and `CD_PROP_INT32`. It makes them a bit more specific and removes
unnecessary abbreviations.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D7980
|
|
This was missing in an earlier commit.
|
|
I found this pattern in depsgraph code more than once.
|
|
Previously, this function would expect a callback function as parameter.
This behavior is now in Map.lookup_or_add_cb. The new version just
takes the key and value directly.
|
|
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.
|
|
We plan to use the "blender" namespace in other modules as well.
|
|
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.
|
|
|
|
|
|
|
|
Change the seed from 0 to 1, so BLI_ghash_performance_test doesn't
assert with duplicate keys.
|
|
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
|
|
|
|
|
|
No functional changes
|
|
This makes it easier to manually run the `abcls` when a test fails, aiding
inspection & fixing.
No function changes to actual Blender code.
|
|
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.
|
|
|
|
Thanks @LazyDodo for the help!
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.
|
