Relax limits of FCurve Bézier handles during evaluation. FCurve handles
can be scaled down to avoid the curve looping backward in time. This
scaling was done correctly but over-carefully, posing unnecessary
limitations on the possible slope of FCurves. This commit changes the
scaling approach such that the FCurve can become near-vertical.
Bump Blender's subversion from 291.0.1 to 291.0.2 to ensure that older
animation files are correctly updated.
Reviewed By: sybren
Differential Revision: https://developer.blender.org/D8752
Write custom properties (aka ID properties) to Alembic, to the
`.userProperties` compound property.
Manifest Task: https://developer.blender.org/T50725
Scalar properties (so single-value/non-array properties) are written as
single-element array properties to Alembic. This is also what's done by
Houdini and Maya exporters, so it seems to be the standard way of doing
things. It also simplifies the implementation.
Two-dimensional arrays are flattened by concatenating all the numbers
into a single array. This is because ID properties have a limited type
system. This means that a 3x3 "matrix" could just as well be a list of
three 3D vectors.
Alembic has two container properties to store custom data:
- `.userProperties`, which is meant for properties that aren't
necessarily understood by other software packages, and
- `.arbGeomParams`, which can contain the same kind of data as
`.userProperties`, but can also specify that these vary per face of a
mesh. This property is mostly intended for renderers.
Most industry packages write their custom data to `.arbGeomParams`.
However, given their goals I feel that `.userProperties` is the more
appropriate one for Blender's ID Properties.
The code is a bit more involved than I would have liked. An
`ABCAbstractWriter` has a `uniqueptr` to its `CustomPropertiesExporter`,
but the `CustomPropertiesExporter` also has a pointer back to its owning
`ABCAbstractWriter`. It's the latter pointer that I'm not too happy
with, but it has a reason. Getting the aforementioned `.userProperties`
from the Alembic library will automatically create it if it doesn't
exist already. If it's not used to actually add custom properties to, it
will crash the Alembic CLI tools (and maybe others too). This is what
the pointer back to the `ABCAbstractWriter` is used for: to get the
`.userProperties` at the last moment, when it's 100% sure at least one
custom property will be written.
Differential Revision: https://developer.blender.org/D8869
Reviewed by: sergey, dbystedt
These were disabled in the newboolean merge commit.
This commit renables them, using the original 'FAST' solver
so that the result objects need not change.
A TODO to add more tests using the 'EXACT' solver,
though most functionality there is now covered by unit gtests.
This is for design task T67744, Boolean Redesign.
It adds a choice of solver to the Boolean modifier and the
Intersect (Boolean) and Intersect (Knife) tools.
The 'Fast' choice is the current Bmesh boolean.
The new 'Exact' choice is a more advanced algorithm that supports
overlapping geometry and uses more robust calculations, but is
slower than the Fast choice.
The default with this commit is set to 'Exact'. We can decide before
the 2.91 release whether or not this is the right choice, but this
choice now will get us more testing and feedback on the new code.
This adds a new `--debug-exit-on-error` flag. When it is set, Blender
will abort with a non-zero exit code when there are internal errors.
Currently, "internal errors" includes memory leaks detected by
guardedalloc and error/fatal log entries in clog.
The new flag is passed to Blender in various places where automated
tests are run. Furthermore, the `--debug-memory` flag is used in tests,
because that makes the verbose output more useful, when dealing
with memory leaks.
Reviewers: brecht, sergey
Differential Revision: https://developer.blender.org/D8665
Add a new depsgraph builder class that includes invisible objects and
use that in the Alembic exporter.
Alembic supports three options for visibility, "visible", "inherited",
and "hidden". This means that parents can be hidden and still have
visible children (contrary to USD, where invisibility is used to prune
an entire scene graph subtree). Because of this, the visibility is
stored on the transform node, as that represents the Object in Blender
and thus keeps the Alembic file as close to Blender's own structure as
possible.
Reviewed By: Sergey
Differential Revision: https://developer.blender.org/D8595
Rename test `alembic_tests` to `alembic_export_tests`, so that its name
is consistent with the Python file containing the tests,
`alembic_export_tests.py`.
No functional changes.
Instead of checking for the length of a list, just handle the error that
occurs when the length is incorrect.
No functional changes to any actual test.
And make them part of the blender_test runner. The one exception is blenlib
performance tests, which we don't want to run by default. They remain in their
own executable.
Differential Revision: https://developer.blender.org/D8498
The abbreviation 'init' is brief, unambiguous and already used
in thousands of places, also initialize is often accidentally
written with British spelling.
Add our own copy of the gtest discovery scripts from CMake a few reasons:
* Use the very latest version which supports PRE_TEST for Windows
* Fix usage of [] symbols in file paths that fail with the zsh shell
* Disable asan leak checker when discovering tests
This means Windows also no longer requires the very latest CMake 3.18.
This bumps the minimum requirement for cmake from 3.10 to 3.18 on windows
if `WITH_GTESTS` is enabled.
Reviewed By: sergey brecht sybren campbellbarton
Differential Revision: https://developer.blender.org/D8405
The buildbot uses a separate `CMAKE_INSTALL_PREFIX`. This means that
the unit test could not find its USD JSON files in the build directory.
Using `${CMAKE_INSTALL_PREFIX}` instead of `$<TARGET_FILE_DIR:blender>`
solved this.
MSVC does need the wholearchive flag but it was not set,
so no tests were actually linked into the binary.
Reviewed By: sybren
Differential Revision: https://developer.blender.org/D8404
When definining static variables that own memory, you should
use the "construct on first use" idiom. Otherwise, you'll get
a warning when Blender exits.
More details are provided in D8354.
Differential Revision: https://developer.blender.org/D8354
This matches the change that was done to the bevel modifier so that the
interface for the modifier, the active tool, and the operator are consistent.
This commit extends the refactor to the bmesh implementation too, so
that the parameters in the implementation don't stray too far from what
is exposed.
Tests are adjusted and still pass.
Implementation of lerp without a function requires repeating one of
the arguments, which is not ideal. To avoid that, add a new function
to the driver namespace. In addition, provide a function for clamping
between 0 and 1 to support easy clamped lerp, and a smoothstep function
from GLSL that is somewhat related.
The function implementations are added to a new bl_math module.
As an aside, add the round function and two-argument log to the
pylike expression subset.
Differential Revision: https://developer.blender.org/D8205
This updates the usage of integer types in code I wrote according to our new style guides.
Major changes:
* Use signed instead of unsigned integers in many places.
* C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`).
* Hash values for C++ containers are 64 bit wide now (instead of 32 bit).
I do hope that I broke no builds, but it is quite likely that some compiler reports
slightly different errors. Please let me know when there are any errors. If the fix
is small, feel free to commit it yourself.
I compiled successfully on linux with gcc and on windows.
Instead of depending on static initialization order of globals use
static variables within functions. Those are initialized on first use.
This is every so slighly less efficient, but avoids a full class of problems.
CMake, when it's configuring the project, runs the `blender_test` test
runner (if it exists from a previous build) to discover which tests it
contains. At this time none of the tests themselves are run, so it's not
that useful to run ASAN and have it break things when there are memory
leaks.
This commit disables ASAN by injecting `ASAN_OPTIONS="detect_leaks=0"` in
the environment variables.
It is not enough to use `set(ENV{ASAN_OPTIONS} "detect_leaks=0")` in
`tests/gtests/runner/CMakeLists.txt`, as it wouldn't be passed to the child
process.
This commit is a followup of {D7649}, and ports the USD tests to the new
testing approach. It moves test code from `tests/gtests/usd` into
`source/blender/io/common` and `source/blender/io/usd`, and adjusts the
use of namespaces to be consistent with the other tests.
I decided to put one test into `io/usd/tests`, instead of
`io/usd/intern`. The reason is that this test does not correspond with a
single file in that directory; instead, it tests Blender's integration
with the USD library itself.
There are two new CLI arguments for the Big Test Runner:
- `--test-assets-dir`, which points to the `lib/tests` directory in the
SVN repository. This allows unit tests to find test assets.
- `--test-release-dir`, which points to `bin/{BLENDER_VERSION}` in the
build directory. At the moment this is only used by the USD test.
The CLI arguments are automatically passed to the Big Test Runner when
using `ctest`. When manually running the tests, the arguments are only
required when there is a test run that needs them.
For more info about splitting some code into 'common', see
rB084c5d6c7e2cf8.
No functional changes to the tests themselves, only to the way they are
built & run.
Differential Revision: https://developer.blender.org/D8314
Reviewed by: brecht, mont29
This commit introduces a new way to build unit tests. It is now possible
for each module to generate its own test library. The tests in these
libraries are then bundled into a single executable.
The test executable can be run with `ctest`. Even though the tests
reside in a single executable, they are still exposed as individual
tests to `ctest`, and thus can be selected via its `-R` argument.
Not yet ported tests still build & run as before.
The following rules apply:
- Test code should reside in the same directory as the code under test.
- Tests that target functionality in `somefile.{c,cc}` should reside in
`somefile_test.cc`.
- The namespace for tests is the `tests` sub-namespace of the code under
test. For example, tests for `blender::bke` should be in
`blender::bke:tests`.
- The test files should be listed in the module's `CMakeLists.txt` in a
`blender_add_test_lib()` call. See the `blenkernel` module for an
example.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7649
