Unit tests veryfying expectation for curves::nurbs::calculate_evaluated_num().
Expectation is computed from closed form expressions rather then hard coded
values. Purpose for this is to make the tests easier to adjust if, for example,
parameter sampling pattern is changed. It should also make them easier to read
and understand.
Additional purpose is to create a baseline and verify changes for #144000.
Implementation is essentially examples from:
https://link.springer.com/book/10.1007/978-3-642-59223-2
Pull Request: https://projects.blender.org/blender/blender/pulls/143920
Replaces pointer based EXPECT_EQ_ARRAY with EXPECT_EQ_SPAN in most cases
as they already used spans (or span compatible datastructures).
Currently EXPECT_EQ_ARRAY only takes in one size variable and doesn't
compare the number of elements between arguments (requiring an
additional line to do so).
This should make the code cleaner and safer. Goal is also to promote
the use Spans in new test code.
Pull Request: https://projects.blender.org/blender/blender/pulls/140340
This change moves the tests data files and publish folder of assets
repository to the main blender.git repository as LFS files.
The goal of this change is to eliminate toil of modifying tests,
cherry-picking changes to LFS branches, adding tests as part of a
PR which brings new features or fixes.
More detailed explanation and conversation can be found in the
design task.
Ref #137215
Pull Request: https://projects.blender.org/blender/blender/pulls/137219
* Use .empty() and .data()
* Use nullptr instead of 0
* No else after return
* Simple class member initialization
* Add override for virtual methods
* Include C++ instead of C headers
* Remove some unused includes
* Use default constructors
* Always use braces
* Consistent names in definition and declaration
* Change typedef to using
Pull Request: https://projects.blender.org/blender/blender/pulls/132361
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
Seems to be a copy-paste error: the first 3 columns
were only compared as float3, not as float4.
Only affected validness of regression tests which might have
missed an actual mismatch between matrices. Likely, all tests
were valid, and this change did not discover failures.
The goal is to solve confusion of the "All rights reserved" for licensing
code under an open-source license.
The phrase "All rights reserved" comes from a historical convention that
required this phrase for the copyright protection to apply. This convention
is no longer relevant.
However, even though the phrase has no meaning in establishing the copyright
it has not lost meaning in terms of licensing.
This change makes it so code under the Blender Foundation copyright does
not use "all rights reserved". This is also how the GPL license itself
states how to apply it to the source code:
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software ...
This change does not change copyright notice in cases when the copyright
is dual (BF and an author), or just an author of the code. It also does
mot change copyright which is inherited from NaN Holding BV as it needs
some further investigation about what is the proper way to handle it.
This patch implements the matrix types (i.e:float4x4) by making heavy
usage of templating. All matrix functions are now outside of the vector
classes (inside the blender::math namespace) and are not vector size
dependent for the most part.
###Motivations
The goal/motivations of this rewrite are the same as the Vector C++ API (D13791):
- Template everything for making it work with any types and avoid code duplication.
- Use functional style instead of Object Oriented function call to allow a simple compatibility layer with GLSL syntax (see T103026 for more details).
- Allow most convenient constructor syntax and accessors (array subscript `matrix[c][r]`, or component alias `matrix.y.z`).
- Make it cover all features the current C API supports for adoption.
- Keep compilation time and debug performance somehow acceptable.
###Consideration:
- The new `MatView` class can be generated by `my_float.view<NumCol, NumRow, StartCol, StartRow>()` (with the last 2 being optionnal). This one allows modifying parts of the source matrix in place. It isn't pretty and duplicates a lot of code, but it is needed mainly to replace `normalize_m4`. At least I think it is a good starting point that can refined further.
- An exhaustive list of missing `BLI_math_matrix.h` functions from the new API can be found here P3373.
- This adds new Rotation types in order to have a clean API. This will be extended when we port the full Rotation API. The types are made so that they don't allow implicit down-casting to their vector representation.
- Some functions make direct use of the Eigen library, bypassing the Eigen C API defined in `intern/eigen`. Its use is contained inside `math_matrix.cc`. There is conflicting opinion wether we should use it more so I contained its usage to almost the tasks as in the C API for now.
Reviewed By: sergey, JacquesLucke, HooglyBoogly, Severin, brecht
Differential Revision: https://developer.blender.org/D16625
Expand unit test for `BKE_fcurve_active_keyframe_index()` to test edge
cases better.
This also introduces a new test macro `EXPECT_BLI_ASSERT()`, which can be
used to test that an assertion fails successfully.
No functional changes to actual Blender code.
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
While it looks more longer, but also contains more comments
about what's going on.
Surely, this function almost never breaks and investing time
into maintaining its tests is not that important, but we should
have a good, clean, understandable tests so they act as a nice
example of how they are to be written. Especially important to
show correct language usage, without old school macros magic.
Doing this at a lunch breaks, so will be series of some updates
in the area.
