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
When running the render test for EEVEE-Next the command printed on
the report to update the reference images was incorrect. In stead of
displaying
`BLENDER_TEST_UPDATE=1 ctest -R eevee_next` it displayed
`BLENDER_TEST_UPDATE=1 ctest -R eevee next`.
The cause of this is that the title of the report is used to create
the command. EEVEE-Next has a space in its title which generates
an incorrect command.
A quick fix would be to replace spaces with underscores. But it would
be better to fix this more clearly by adding an attribute containing the
engine name.
This PR adds a `set_engine_name` method to the Report class. By
default the engine name is set based on the title.
Pull Request: https://projects.blender.org/blender/blender/pulls/117503
The part of the patch wasn't properly applied from a working branch,
and it wasn't very visible because the development environment already
had all files on disk.
Pull Request: https://projects.blender.org/blender/blender/pulls/117504
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.
Last month we have been in the process of fixing the render tests of EEVEE-Next.
These render tests had some issues. Currently we are in a state that render
differences can be explained or related to an existing issue.
Having these render tests will also enable testing differences between Metal and OpenGL.
The new setup alters the position of the reflection probe so it doesn't intersect the ground
or the sphere at the same time. An offset was added, which adds a small difference
between cycles and eevee-next renders.
There is a known issue with the HiZ buffers when render size is too small. We change the
reflection probe render size as a temporary fix.
Pull Request: https://projects.blender.org/blender/blender/pulls/117447
Splits the flag `..._FLAG_INSERTNEEDED` between autokey and
manual keying. The fact that this flag was shared between the two
systems has been the cause of issues in the past. It wouldn't
let you insert a keyframe even though you explicitly used an operator
to do so.
In order to be clearer what options are used where, the user preferences
have been reordered.
By default "Only Insert Needed" will be enabled for auto-keying, but not for manual keying.
The versioning code will enable both if it was enabled previously.
# Code side changes
The keying system has flags that define the behavior
when keys are inserted. Some of those flags were shared
between keying and auto-keying. Some were only used for
auto-keying.
To clarify that, prefix flags that used exclusively in one or the other
system with `AUTOKEY`/`MANUALKEY`
Also the flag name on the user preferences and the tool settings was renamed.
Previously it was called `autokey_flag`. To indicated that it is not only used
for autokeying, rename it `keying_flag`.
Fixes: #73773
Pull Request: https://projects.blender.org/blender/blender/pulls/115525
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
Loading pre-4.0.20 node groups with sockets using subtypes causes
broken socket identifiers. This is because the node tree interface now
expects sockets to use the base identifiers ("NodeSocketFloat" instead
of "NodeSocketFloatFactor" etc.).
To correct this the conversion code now replaces socket idnames that
include a subtype suffix with their base names. This fix is also applied
to files between versions 4.0.20 and 4.1.10, where the socket types
may have been converted incorrectly.
Pull Request: https://projects.blender.org/blender/blender/pulls/117133
Render test would hide objects from probes. It still referred to
the old name of the spherical probes. This change will replace it
with the correct name.
It also hides objects from the planar probes as they were also
recently added.
Pull Request: https://projects.blender.org/blender/blender/pulls/116093
The foreach_get/foreach_set methods of bpy_prop_array get/set the entire
contents of the array, but they were checking that the length of the
input sequence was equal to the length of the current array dimension
rather than the total length of all dimensions of the array.
This would read/write memory after the end of the passed in sequence
when the property was a multidimensional array. Performing
`foreach_get` with a Python list with length matching the length of the
current dimension of a multidimensional array would crash a debug build
due to the trailing pad bytes of the temporarily allocated array being
overwritten.
This patch fixes `pyprop_array_foreach_getset` by changing the function
used to get the expected sequence size, to the RNA function that gets
the total length of the array across all its dimensions.
The tests have be updated to additionally test multidimensional array
properties.
Pull Request: https://projects.blender.org/blender/blender/pulls/116457
The bone collection unit tests in Python were failing, but this failure
was not propagated to `ctest` and thus went unnoticed.
Both issues are now fixed.
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.
Instead of moving bone collections by absolute index, they can now be
moved by manipulating `.child_number`. This is the relative index of the
bone collection within the list of its siblings.
This replaces the much more cumbersome `collections.move_to_parent()`
function. Since that function is now no longer necessary (it's been
replaced by assignment to `.parent` and `.child_number`), it's removed
from RNA. Note that this function was never part of even a beta build of
Blender.
This PR changes two things
Move setup/cleanup code into `setUp`/`tearDown`
Change the `_fcurve_paths_match` to raise an error instead of returning a bool.
That makes it easier to see what the actual error is.
Pull Request: https://projects.blender.org/blender/blender/pulls/116816
Add unit tests for the user preference option "Insert Needed"
Basic tests for objects and bones that check if autokeying in
combination with "Insert Needed" only
* keys all location channels on the first key
* keys only the modified channel on the second key
It is supposed to add only keyframes that have been affected
by the used transform operation.
E.g. translating an object will only add keys on translation keys.
The behavior of keying all property array channels first, and then
only add keys on values that have actually changed may change
in the future. Ideally it would only key actual changes to begin
with. But there is no way to do this right now.
Pull Request: https://projects.blender.org/blender/blender/pulls/116419
Moving a bone collection to another parent is now possible in Python by
assigning to `bone_collection.parent`.
Thanks to Sergey for the implementation.
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 `bone_collection.bones_recursive` property that returns the set of
bones assigned to that bone collection or any of its child collections.
This property is implemented in Python, as that made it considerably
simpler to create the set semantics.
Use `bpy.ops.wm.read_homefile(use_factory_startup=True)` to load the
default 'homefile'. Otherwise Blender will load the saved-as-default file,
which can be quite different from the default startup file.
Add a read-only property `bone_collection.parent` to RNA that returns
the parent bone collection.
This performs two scans of the array (one to find the bone collection's
index, and the other to find the parent index). This might look bad, but
as long as `Object.children` still loops, in Python, over all of
`bpy.data.objects`, this should also be acceptable.
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.
In preparation to the upcoming refactor of the keying set code,
extend the unit tests with more sophisticated
tests for "Insert Available".
This PR tests
* key available using the preference setting with autokeying on an object and a bone
* key available using the keyingset "Available"
Pull Request: https://projects.blender.org/blender/blender/pulls/116327
This was added at the start of the project, as a way for the source
library to control what would be overridable by the user of the data
(production files).
The implementation never went beyond the experimental area, and only
exposed in the python API then. The idea has been superseeded by the
'cherry-pick' design, so there is no point in keeping this code any
longer.
Add support for enum values in ID properties.
This is needed for the "Menu Switch" node implementation (#113445) which
relies on ID properties for the top-level modifier UI.
Enums items can optionally be added to the UI data of integer
properties. Each property stores a full set of the enum items to keep
things simple.
Enum items can be added to properties using the `id_properties_ui`
function in the python API. A detailed example can be found in the
`bl_pyapi_idprop.py` test.
There is currently no support yet for editing enum items through the UI.
This is because the "Edit Property" feature is implemented entirely
through a single operator (`WM_OT_properties_edit`) and its properties.
Buttons to add/remove/move items would be operators changing another
operator's properties. A refactor of the custom properties UI is likely
required to make this work.
Pull Request: https://projects.blender.org/blender/blender/pulls/114362
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
Expose the ID type identifier as defined by the `rna_enum_id_type_items`
enum items as `ID.id_type` in RNA.
Add some test to `id_management` ensuring that all ID types exposed in
`bpy.data` have a valid `id_type` value, i.e. that they have a matching
entry in `rna_enum_id_type_items`.
This will hopefully prevent future cases like #115151 .
When animators want to key something in the viewport,
the code needs to know *which properties* should be keyed of that selected thing.
So far that was done with keying sets, and a pop-up that let's
you choose the keying set to use. You can get rid of the popup by
choosing a keying set ahead of time. But that is also not always desirable.
That pop-up is quite confusing and gives way too many options.
To simplify this process this PR adds a User Preference option to choose one or more of:
* Location
* Rotation
* Scale
* Rotation Mode
* Custom Properties
Now whenever the `I` key is pressed in the viewport,
and no keying set is enabled, it reads the preferences for which channels to insert.
# User Facing changes
* The popup will not be shown when pressing the hotkey,
but you can still explicitly use keying sets by going to the menu
* Which channels are keyed is defined by a User Preference setting under animation
* when a keying set is used explicitly, the User Preference settings are ignored
Part of #113278
Pull Request: https://projects.blender.org/blender/blender/pulls/113504
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