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
Adds a python test script for the field inferencing mechanism in geometry nodes.
Tests various combinations of field-to-value and value-to-field combinations as well as unconnected base nodes. Zones are tested because they can require multiple passes to resolve, especially when nesting.
Testing is based on socket display shapes as a proxy for field type, since the field type is not exposed in RNA yet. Likewise, testing for red links caused by field dependencies can only be done indirectly currently, because such links are not actually made invalid by the inferencing code, and just drawn red by the editor.
Pull Request: https://projects.blender.org/blender/blender/pulls/114903
Some tests like cycles, sequencer and compositor batch together multiple
tests in a single Blender invocation. This makes them run faster, but
makes debugging harder. This is an option to disable that batching.
Pull Request: https://projects.blender.org/blender/blender/pulls/114603
Cover the current behavior of keyframe insertion with unit tests,
so the changes planned in #113278 are less likely to break things.
Unit tests added:
InsertKeyTest
very basic test to ensure keying things by
name or with a keying set adds the right keys
VisualKeyingTest
check if visual keying produces the
correct keyframe values
CycleAwareKeyingTest
check if cycle aware keying remaps
the keyframes correctly and adds fcurve modifiers
Pull Request: https://projects.blender.org/blender/blender/pulls/114465
User a Blender wrapper `tests/utils/blender_headless.py` to runs a
graphical instance of Blender within a headless weston compositor.
Currently only WAYLAND is supported as a back-end, support for other
platforms is possible. The tests can run from X11 since the tests don't
depend on existing instances of X11 or WAYLAND.
- Each test runs a separate headless instance of WESTON
since the overhead is minimal, this allows tests to run in parallel
without interfering with each other.
- There is a CMake option WESTON_BIN, when left empty the weston
from LIBDIR is used. Otherwise this can point to the weston binary
installed on the users system.
- In most cases simulated events are needed to implement these tests
(running blender with `--enable-event-simulate`).
- This commit adds 14 undo tests - simulating user interaction as well
as undo/redo actions, ensuring the desired result is reached.
Other kinds of UI tests could be added in the future.
Ref !114164
Enable tests for EEVEE Next.
As a workaround for allowing the use of EEVEE Next (still an
experimental feature) with `--factory-startup`, `arg_handle_engine_set`
enables the feature when `-E BLENDER_EEVEE_NEXT` is used.
In addition, EEVEE Next is always registered, so it's available when
calling `WM_init`.
If it's actually disabled, it will be immediately unregistered after that.
Notes:
- `get_gpu_device_type` always fails with error:
> GPU API is not available in background mode
- Setup and tests are the same as EEVEE. There are many tests that
only make sense for Cycles, and many EEVEE Next features that are
not actually tested.
Pull Request: https://projects.blender.org/blender/blender/pulls/112161
This is fairly brute force and rough, but there are quite a few old
files in there, helps a bit with versioning and readfile code testing.
Note: Five files are currently excluded since failing in debug builds
at least, most of the time for memleaks issues. The two other 'errors'
may also not be actual issues, but this needs to be investigated further.
Also, in the future, when time allows, it may be better to generate a
set of dedicated testing files, with as many official releases versions
as possible?
Re. #112649.
This simplifies running built-in IO tests with:
ctest -R bf_io_
Also use "bf_io_" prefix for the libraries since it was already used
by some and it's a useful hint the libraries are used for IO.
Part 3/3 of #109135, #110272
Switch to new node group interfaces and deprecate old DNA and API.
This completes support for panels in node drawing and in node group
interface declarations in particular.
The new node group interface DNA and RNA code has been added in parts
1 and 2 (#110885, #110952) but has not be enabled yet. This commit
completes the integration by
* enabling the new RNA API
* using the new API in UI
* read/write new interfaces from blend files
* add versioning for backward compatibility
* add forward-compatible writing code to reconstruct old interfaces
All places accessing node group interface declarations should now be
using the new API. A runtime cache has been added that allows simple
linear access to socket inputs and outputs even when a panel hierarchy
is used.
Old DNA has been deprecated and should only be accessed for versioning
(inputs/outputs renamed to inputs_legacy/outputs_legacy to catch
errors). Versioning code ensures both backward and forward
compatibility of existing files.
The API for old interfaces is removed. The new API is very similar but
is defined on the `ntree.interface` instead of the `ntree` directly.
Breaking change notifications and detailed instructions for migrating
will be added.
A python test has been added for the node group API functions. This
includes new functionality such as creating panels and moving items
between different levels.
This patch does not yet contain panel representations in the modifier
UI. This has been tested in a separate branch and will be added with a
later PR (#108565).
Pull Request: https://projects.blender.org/blender/blender/pulls/111348
Tests must be enabled manually using the CMake flag `WITH_COMPOSITOR_REALTIME_TEST`. Reasons are F12 for realtime compositor is experimental and buildbots have no GPU. Failing tests are excluded.
Pull Request: https://projects.blender.org/blender/blender/pulls/109878
