This patch removes the references for the GPU tests and uses the CPU
references for both CPU and GPU, since they are expected to match. This
also unifies the tests scripts into a single script with an argument
for execution device.
Both the draw manager and gpu backend used the same compilation
directive for enablement. This PR seperates them into
`WITH_GPU_DRAW_TESTS` for draw manager related tests and
`WITH_GPU_BACKEND_TESTS` for gpu backend related tests.
Pull Request: https://projects.blender.org/blender/blender/pulls/132018
OptiX OSL tests were previously disabled due to a GPU driver bug
resulting in many tests failing unexpectedly.
The new driver version is now out with the fix so we can now enable
OptiX OSL testing.
This commit also updates the OptiX OSL block list with better comments,
and more tests that are known to fail and need investigating.
Ref: #123012
Pull Request: https://projects.blender.org/blender/blender/pulls/129280
Render tests can still fail. This change will disable them until they
are in a better shape. Reduces confusion when running cycles GPU render
tests.
Known issues:
- Render in batch can take forever due to a locking issue
- Headless rendering is still in development
- Particle hair rendering is broken.
Pull Request: https://projects.blender.org/blender/blender/pulls/131964
In a previous commit the Principled BSDF tests were renamed from
`principled_...` to `principled_bsdf_...`. The proposal was made to
also rename the folder these tests were in to `principled_bsdf` for the
sake of consistency. This is what this commit does.
Pull Request: https://projects.blender.org/blender/blender/pulls/131771
Some changes to how argparse is used in render tests:
1. Use the common approach of one dash for single-letter options (`-b`)
and two dashes for longer options (`--blender`). In this commit that
just means changing single-dashed (`-testdir`) to double-dashed
(`--testdir`).
2. Remove unnecessary `nargs` arguments. The code was telling `argparse`
to put CLI arguments into a list of one item, and then had code to
turn that one-item list into the item itself. I've just removed the
`nargs` argument altogether, as that just produces the desired
value without requiring more code.
I've also removed `nargs="+"` from the handling of the `--blender`
parameter, as that allowed for multiple occurrences of `--blender
{path}` but was silently ignoring all of those except the first.
To ensure that required arguments are present, the code now uses
`required=True` instead of `nargs`.
3. Add a `description` parameter so that `--help` shows what the
test script actually does. Also it helps people (like me) who want
to figure out which blend file is actually being opened by the
test, without making the test itself more verbose.
No functional changes, except that you now cannot add multiple
`--blender` arguments any more (the CLI invocation will fail). This wasn't
used anywhere I could find, though.
Pull Request: https://projects.blender.org/blender/blender/pulls/131666
Adding object conversion tests to verify the refactored object type
conversion code works as intended.
The object conversion operator `exec()` function is restructured by
PR #130668 to clean up code path for better readability, since it's a
relatively big change, this test is put up to verify that:
- For supported object type pairs, converted objects would have the
expected target object type.
- For unsupported/unimplemented type pairs, the test expect the
converted object to have the same type as the source object.
- Verify that the code behaviour stays exactly the same as prior
to the change in #130668, including code logic that are later subject
to change and redesign, in which case this test file/script would need
to be updated accrodingly.
This test added such files:
- `tests/data/modelling/object_conversion.blend`: Sets up differnt types
of input objects and their expected converted object combinations.
- `tests/python/object_conversion.py`: Does mesh equal checks for
objects that are converted to mesh against expected objects in the
blend file, and does object type checks for other target types.
Note:
This test currently does not do topology-level equal check except for
when target object type is `MESH`. Equal check hasn't been implemented
for other object types yet, but ideally in the future we should use
topology check on top of type check for other object types as well.
See https://projects.blender.org/blender/blender/pulls/130668
Pull Request: https://projects.blender.org/blender/blender/pulls/130738
Specifically coverage of various YUV formats (4:2:0 and 4:4:4),
some bit depths (most 8 bit, some 10 bit), various colorspace
settings (untagged, bt709), and YUV color ranges (regular/limited vs
full/pc).
build_test_movies.sh in there generates all the (tiny) movie files
out of input color_chart.png using command line ffmpeg.
In case the process creashes, the prints about blendfiles being
processed could fail to be captured by the test framework.
And split these tests in 32 slices now, 8 was becomming way too slow to
complete for each test.
This commit takes the 'Slotted Actions' out of the experimental phase.
As a result:
- All newly created Actions will be slotted Actions.
- Legacy Actions loaded from disk will be versioned to slotted Actions.
- The new Python API for slots, layers, strips, and channel bags is
available.
- The legacy Python API for accessing F-Curves and Action Groups is
still available, and will operate on the F-Curves/Groups for the first
slot only.
- Creating an Action by keying (via the UI, operators, or the
`rna_struct.keyframe_insert` function) will try and share Actions
between related data-blocks. See !126655 for more info about this.
- Assigning an Action to a data-block will auto-assign a suitable Action
Slot. The logic for this is described below. However, There are cases
where this does _not_ automatically assign a slot, and thus the Action
will effectively _not_ animate the data-block. Effort has been spent
to make Action selection work both reliably for Blender users as well
as keep the behaviour the same for Python scripts. Where these two
goals did not converge, reliability and understandability for users
was prioritised.
Auto-selection of the Action Slot upon assigning the Action works as
follows. The first rule to find a slot wins.
1. The data-block remembers the slot name that was last assigned. If the
newly assigned Action has a slot with that name, it is chosen.
2. If the Action has a slot with the same name as the data-block, it is
chosen.
3. If the Action has only one slot, and it has never been assigned to
anything, it is chosen.
4. If the Action is assigned to an NLA strip or an Action constraint,
and the Action has a single slot, and that slot has a suitable ID
type, it is chosen.
This last step is what I was referring to with "Where these two goals
did not converge, reliability and understandability for users was
prioritised." For regular Action assignments (like via the Action
selectors in the Properties editor) this rule doesn't apply, even though
with legacy Actions the final state ("it is animated by this Action")
differs from the final state with slotted Actions ("it has no slot so is
not animated"). This is done to support the following workflow:
- Create an Action by animating Cube.
- In order to animate Suzanne with that same Action, assign the Action
to Suzanne.
- Start keying Suzanne. This auto-creates and auto-assigns a new slot
for Suzanne.
If rule 4. above would apply in this case, the 2nd step would
automatically select the Cube slot for Suzanne as well, which would
immediately overwrite Suzanne's properties with the Cube animation.
Technically, this commit:
- removes the `WITH_ANIM_BAKLAVA` build flag,
- removes the `use_animation_baklava` experimental flag in preferences,
- updates the code to properly deal with the fact that empty Actions are
now always considered slotted/layered Actions (instead of that relying
on the user preference).
Note that 'slotted Actions' and 'layered Actions' are the exact same
thing, just focusing on different aspects (slot & layers) of the new
data model.
The "Baklava phase 1" assumptions are still asserted. This means that:
- an Action can have zero or one layer,
- that layer can have zero or one strip,
- that strip must be of type 'keyframe' and be infinite with zero
offset.
The code to handle legacy Actions is NOT removed in this commit. It will
be removed later. For now it's likely better to keep it around as
reference to the old behaviour in order to aid in some inevitable
bugfixing.
Ref: #120406
This adds feature parity with Cycles regarding light and shadow liking.
Technically, this extends the GBuffer header to 32 bits, and uses
the top bits to store the object's light set membership index.
The same index is also added to `ObjectInfo` in place of padding bytes.
For shadow linking, the shadow blocker sets bitmask is stored per
tilemap. It is then used during the GPU culling phase to cull objects
that do not belong to the shadow's sets.
Co-authored-by: Clément Foucault <foucault.clem@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/127514
This implements versioning code to go from legacy to layered action.
The versioning is only triggered when the experimental flag for
Multi-Slot actions is enabled.
All the actions are converted in place, which should be fine because
of backwards and forwards compatibility with layered actions.
Pull Request: https://projects.blender.org/blender/blender/pulls/127842
This adds a new type of zone to Geometry Nodes that allows executing some nodes
for each element in a geometry.
## Features
* The `Selection` input allows iterating over a subset of elements on the set
domain.
* Fields passed into the input node are available as single values inside of the
zone.
* The input geometry can be split up into separate (completely independent)
geometries for each element (on all domains except face corner).
* New attributes can be created on the input geometry by outputting a single
value from each iteration.
* New geometries can be generated in each iteration.
* All of these geometries are joined to form the final output.
* Attributes from the input geometry are propagated to the output
geometries.
## Evaluation
The evaluation strategy is similar to the one used for repeat zones. Namely, it
dynamically builds a `lazy_function::Graph` once it knows how many iterations
are necessary. It contains a separate node for each iteration. The inputs for
each iteration are hardcoded into the graph. The outputs of each iteration a
passed to a separate lazy-function that reduces all the values down to the final
outputs. This final output can have a huge number of inputs and that is not
ideal for multi-threading yet, but that can still be improved in the future.
## Performance
There is a non-neglilible amount of overhead for each iteration. The overhead is
way larger than the per-element overhead when just doing field evaluation.
Therefore, normal field evaluation should be preferred when possible. That can
partially still be optimized if there is only some number crunching going on in
the zone but that optimization is not implemented yet.
However, processing many small geometries (e.g. each hair of a character
separately) will likely **always be slower** than working on fewer larger
geoemtries. The additional flexibility you get by processing each element
separately comes at the cost that Blender can't optimize the operation as well.
For node groups that need to handle lots of geometry elements, we recommend
trying to design the node setup so that iteration over tiny sub-geometries is
not required.
An opposite point is true as well though. It can be faster to process more
medium sized geometries in parallel than fewer very large geometries because of
more multi-threading opportunities. The exact threshold between tiny, medium and
large geometries depends on a lot of factors though.
Overall, this initial version of the new zone does not implement all
optimization opportunities yet, but the points mentioned above will still hold
true later.
Pull Request: https://projects.blender.org/blender/blender/pulls/127331
This PR enabled backend specific rendertest for EEVEE and Workbench.
Some changes that have been made are:
- Add suffix to the test identifying the backend (_opengl, _vulkan, _metal)
- Vulkan render tests are compared with the opengl results.
Most EEVEE tests run as expected there are some issues in the Vulkan
backend that needs to be addressed:
- Fully smooth reflective materials miss lighting.
- Tangent normals are off
None of the workbench tests pass. It has to do with downloading the depth
buffer. In Workbench they are stored as GPU_DEPTH32F_STENCIL8 and downloaded
as FLOAT. We didn't implement it in the vulkan backend yet and currently asserts.
The Vulkan render test run faster compared to OpenGL. On my system around
25-50% faster.
Pull Request: https://projects.blender.org/blender/blender/pulls/126784
This commit adds a new cmake variable `WITH_CYCLES_TEST_OSL`
that runs every Cycles test a second time with OSL enabled.
At the moment only CPU OSL is enabled. There are plans to enable
OptiX OSL in the future when stability issues with OptiX OSL
have been resolved.
Some render tests have been blocked from running until we can figure
out a fix. The most notiable being all the Pricincipled BSDF tests
as some of them are failing due to noise differences.
Ref #123012
Pull Request: https://projects.blender.org/blender/blender/pulls/124601
This handles the transition to EEVEE-Next (now EEVEE).
This removes some things that make no sense to keep
even for compatibility.
- Scene.eevee.light_cache_data
- Scene Light cache operators
- Scene Light cache RNA properties
The remaining legacy properties will be removed later
on to avoid python API breakage.
We keep the identifier of EEVEE-Next as `BLENDER_EEVEE_NEXT`
to avoid addons being incorrectly silently made compatible
with the EEVEE-Next where the Python API is different.
This renaming should be done in 5.0 release.
Thank you EEVEE-Legacy, you served us well.
Pull Request: https://projects.blender.org/blender/blender/pulls/122433
The `io_blendfile_versioning` test is currently one of the slowest
(excluding Cycles ones) in debug builds, it can easily take several
minutes to complete.
This commit split it into several instances, each processing a subset of
all the blendfiles.
This gives a strong speed-up when only running that specific test.
As expected, speedup is neglectable when running the whole test suite
though.
| instances | debug | release | debug all* | release all |
| --------- | ------ | ------- | ---------- | ----------- |
| 1 | 190.95 | 19.39 | 439.54 | 63.51 |
| 4 | 61.80 | 6.81 | N/A | N/A |
| 8 | 38.33 | 5.14 | 435.00 | 58.93 |
| 16 | 33.97 | 4.16 | N/A | N/A |
| 32 | 46.54 | 5.14 | N/A | N/A |
Times are in seconds.
`instances` are the number of tests generated (1 is same as before this
commit).
The first two columns are timings for running the versioning test only,
the last two are timings for the full test suite (excluding Cycles tests
in the debug build case).
This updates OIDN to 2.3.0-beta. The final version is planned to be
released in time for Blender 4.2 Beta. The most relevant changes:
1. Much higher quality when denoising with accurate prefiltering in *high*
quality mode, but at the cost of lower performance (use *balanced*
quality mode to revert to previous *high* quality mode)
2. Added new *fast* quality mode for 1.5-2x higher performance viewport
denoising
3. Lazy device module loading to avoid potential stability issues caused by
drivers of unused devices
4. Release CUDA primary context as soon as the OIDN device gets destroyed
to prevent potential memory leaks
To enable 2 and 3, code changes are needed in Blender, to be committed
separately.
Ref #118455
Pull Request: https://projects.blender.org/blender/blender/pulls/121359
Add code (including RNA wrappers) for:
- Creating, removing, and accessing `Animation` data-blocks.
- Creating and removing layers, strips, and bindings on those `Animation`
data-blocks.
- Accessing those via RNA.
Note that this does not include assignment to any animated data-block,
so it is of limited practical use.
For more info, see #113594.
Pull Request: https://projects.blender.org/blender/blender/pulls/118677
This change makes it so build system and update utilities for Blender builds
are using pre-compiled libraries and other resources attached as Git modules
instead of using checkout of SVN repositories in the parent folder.
The directory layout:
```
* release/datafiles/
* assets/ -> blender-assets.git
* publish/
* ...
* README.txt
* lib/
* darwin_x64/ -> lib-darwin_x64.git
* darwin_arm64/ -> lib-darwin_arm64.git
* linux_x64/ -> lib-linux_x64.git
* windows_x64/ -> lib-windows_x64.git
* tests/
* data/ -> blender-test-data.git
```
The changes about configuring the actual Git sub-modules are not included
into this patch, as those require repository to actually exist before it
can be used.
The assets submodule is enabled by default, and the rest of them are
disabled. This means that if someone runs `git submodule update --init`
they will not get heavy libraries. The platform-specific and tests
related submodules are enabled when using `make update` or `make test`.
All the submodules are tracked: this means that when new commits are
done to the submodule, the blender.git repository is to be updated to
point them to the new hash. This causes some extra manual work, but it
allows to more easily update Blender and its dependencies to known good
state when performing operations like bisect.
Ref #108978
Pull Request: https://projects.blender.org/blender/blender/pulls/117946
Add silently fail option to GPU based render tests. This is a pre-requisite to enable
render tests on the buildbot. By default these render tests will pass silently.
* Test will pass when using the `--pass-silently` arguments.
* Only crashes will be reported as failed tests.
* To find out failing test, review the test reports.
`WITH_GPU_RENDER_TESTS_SILENT` compile option can be used to let tests pass (default)
or fail (default for developers).
Although some tests fail, they still passed. In the generated render report,
the silently passed failures are correctly reported to be failures.
Pull Request: https://projects.blender.org/blender/blender/pulls/117629
This PR disables cycles only render tests for the gpu/viewport based
render engines. These render engines include EEVEE, Workbench, but
also the Hydra viewport engines. Disabling those test would reduce
test time.
Tests that are being disabled are features that are only supported
by Cycles.
- Light groups
- Light linking
- Shadow catcher
- Denoising
- Path guiding
- Reports
Pull Request: https://projects.blender.org/blender/blender/pulls/117540
This change fixes confusion situation when the render output
is an RGBA image: the difference in color was not visible in
the report because alpha channel was all zeros. This is due
to idiff performing per-channel difference.
The solution to this problem is to have separate images for
color and alpha difference, which makes it clear where the
difference actually is coming from.
CurvesGeometry has no ".selection" attribute when all control points
are selected. The earlier code assumed that the attribute always exists.
Also Python tests are added for the "extrude" operator.
Pull Request: https://projects.blender.org/blender/blender/pulls/117095
As discussed in #105407, it can be useful to support returning
a fallback value specified by the user instead of failing the driver
if a driver variable cannot resolve its RNA path. This especially
applies to context variables referencing custom properties, since
when the object with the driver is linked into another scene, the
custom property can easily not exist there.
This patch adds an optional fallback value setting to properties
based on RNA path (including ordinary Single Property variables
due to shared code and similarity). When enabled, RNA path lookup
failures (including invalid array index) cause the fallback value
to be used instead of marking the driver invalid.
A flag is added to track when this happens for UI use. It is
also exposed to python for lint type scripts.
When the fallback value is used, the input field containing
the property RNA path that failed to resolve is highlighted in red
(identically to the case without a fallback), and the driver
can be included in the With Errors filter of the Drivers editor.
However, the channel name is not underlined in red, because
the driver as a whole evaluates successfully.
Pull Request: https://projects.blender.org/blender/blender/pulls/110135
The current handling had a fairly bad issue: multiple calls to
`set_tests_properties` to set envvars of a same test.
This does not work, only the last call is effective, all previous
ones have absolutely no effect.
This has been addressed by moving all 'set envvar for test' logic into a
single CMake function, `blender_test_set_envvars`.
This function takes optional extra envvars if needed, and define a set
of default ones (currently, `PATH` from `PLATFORM_ENV_INSTALL` if
defined, and the 'nuke' `exitcode=0` `LSAN_OPTIONS` if relevant).
NOTE: The way `blender_test_set_envvars` handles extra envvars passed to
it as parameter is fairly basic and unsafe, in that there is no check
whether a same envvar is defined more than once. Think for now this is
an acceptable limitation.
NOTE: Although this commit _should_ be a non-functional change one, the
unification of the handling of all envvars makes it hard to ensure there is no
side effects.
The `PATH` envvar e.g. was set to either `PLATFORM_ENV_INSTALL` if defined,
or a copy of that variable's definition, but only in Windows case. So technically,
the behavior for this envvar is changed.
Bundling many tests in a single binary reduces build time and disk space
usage, but is less convenient for running individual tests command line
as filter flags need to be used.
This adds WITH_TESTS_SINGLE_BINARY to generate one executable file per
source file. Note that enabling this option requires a significant amount
of disk space.
Due to refactoring, the resulting ctest names are a bit different than
before. The number of tests is also a bit different depending if this
option is used, as one uses gtests discovery and the other is organized
purely by filename, which isn't always 1:1.
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/114604
Add a Python unit test that covers some of the armature/bone collections.
Some of these tests cover the same functionality as the C++ tests, albeit
via the Python/RNA API.
Another test was added to check that joining armatures works as expected.
The build scripts are still referring to gpu tests as being opengl.
Although they can also use Metal or Vulkan. This PR only replaces
the work `opengl` with `gpu` for build options.
Special note is that the windows argument `with_opengl_tests` is
also replaced with `with_gpu_tests` for consistency.
Pull Request: https://projects.blender.org/blender/blender/pulls/116030
