The important distinction for the linker flags is not between GCC and Clang,
but between the macOS and Linux.
Differential Revision: https://developer.blender.org/D8023
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.
The issue was caused by wrong conversion happening after some of the
proxies are removed. Easiest solution is to first remove proxies and
then add required converter operations.
Thanks Jeroen for the review!
Channels aren't visually changed by playing back an animation so there
is no need to do this. As rendering channels is using a lot of logic
(filtering animation data, converting fcurves to samples etc) it has an
noticeable overhead.
This change has no functional limitation. Users are still able to do
everything during animation playback. There are other mechanisms in
place that take care of that.
Spring 02_020_A.anim.blend went from 11.8 to 12.0 on a Ryzen 1700. I
didn't test with scenes but it should be more noticeable with more
complex scenes.
Reviewed By: Brecht van Lommel
Differential Revision: https://developer.blender.org/D8073
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.
OSLRenderServices contains a member which is 64 bytes aligned and this
is onlys supported by default allocators in SDK 10.14. Since we take
care of allocation ourselves ignoring the diagnostic is an acceptable
way dealign with it.
AutoPtr class became a sub-class of unique_ptr with some special magic
to mimic behavior of auto_ptr for copy constructor.
The code was already there, but for some reason visual studio did not
set __cplusplus correctly for some reason.
The other change is remove of binary function usage, which is not
needed in the Freestyle code.
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.
Using latest master because of various compilation error fixes.
Brings a lot of recent development. From most interesting parts:
- New threading model.
- Tiny solver.
- Compatibility with C++17.
This is an intermittent state to get all dependencies to compile.
For example, the latest Ceres is needed to bring C++17 support,
but it has bumped minimal requirement to C++14.
Currently all force effectors can only act on cloth when the force is
perpendicular to the surface. This makes sense for wind, but not for
other forces; and the user may want even wind to have some friction.
This changes effector code to output two force vectors - although
you of course can pass the same pointer for both. The force is split
between the two outputs based on a new per-effector setting.
Differential Revision: https://developer.blender.org/D8017
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
Before this, there was one code path that set `context.export_path`, and
a different code path for `context.export_name`, allowing the two to
diverge.
Keeping track of the export path of the export parent (which can be, but
is not always, the Blender parent object) also allows a concrete
subclass of `AbstractHierarchyIterator` to find the `AbstractWriter` for
the export parent. In case of exporting to Alembic this is important, as
it's not possible to simply give the Alembic library the full export
path of an object like we do in the Universal Scene Description (USD)
exporter; Alembic needs the C++ object of the parent.
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 reason was the datablock is changed but it was not tagged for depsgraph refresh.
In some cases it could be possible to tag several times the same datablock, but as this is not the case all the times and the number of tags is always very small, it doesn't worth a complex code to keep a memory list of the datablocks to tag.
This removes G_FILE_HISTORY, G_FILE_SAVE_COPY & G_FILE_USERPREFS.
Using file-flags made logic harder to follow since it's not so clear
which flags are expected to be in G.fileflags & which are meant to be
set and passed as arguments, these are shared between read & write
functions too.
Add BlendFileWriteParams so options which don't need to be stored
aren't mixed up with flags that are stored for reuse.
These functions are very specific to the mode.
More modes can support snap, and there is no reason to keep all
callbacks for each mode in the transform_snap.c file.
This makes any operation (including mere bone selection) several times
faster on some complex production character, since we typically now only
need to diff a single ID, instead of tens of them.
We decided to use our own map data structure in general for better
readability and performance.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D7987
By using own path construction instead of handy printf-like functions,
we get a 10% improvement on overall diffing process!
This remains way to slow on some complex production characters, but
always good to have still.
This way "New Collection" is always assigned the same shortcut (N).
Whereas previously it would be automatically assigned the leftover key
from the list of available collections.
Nice side effect is that since N is next to M in most keyboard layouts,
moving to a new collection is super fast by hitting M then N.
{F8630575, size=full}
Paper-cut pointed out by DerekWatts on [devtalk](https://devtalk.blender.org/t/blender-ui-paper-cuts/2596/4211) (thanks!):
{F8630492, size=full}
Reviewed By: HooglyBoogly
Differential Revision: https://developer.blender.org/D8067
Use a median center of polygons as an initial value for volume center
calculation since the volume accumulation quickly generates very large
numbers that become inaccurate if the geometry is too far
from it's current center.
This seems to be an error in rBb91b90f0dd3c9bff3b1a6e563c2cce293722ed16.
I found it, because I could not open the file in T77263 anymore.
Reviewers: sebbas
Differential Revision: https://developer.blender.org/D8065
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`.
