* Adds docstrings to `bl_object.py` and `bl_sculpt.py` tests so that
failure output is more helpful.
* Renames `bl_object.py` class and function to be more inline with other
test naming
Pull Request: https://projects.blender.org/blender/blender/pulls/135417
A recent bug fix to light tree building lead to a issue where some
lights with light linking would incorrectly share nodes in the
light tree.
To help detect failures like this in the future, this commit adds a
test based on the file found in the original report
blender/blender#135200.
Ref: blender/blender-test-data!63
`ColorManagedDisplaySettings`, `ColorManagedViewSettings`,
`ColorManagedInputColorspaceSettings` were affected since these are used
from multiple places (Scene, File output nodes, ..).
Similar to how we are getting the path for `ImageFormatSettings` (which
pretty much has the distinction logic already), we can do so for the
ColorManage Settings as well (piggbacking on the already correct path to
the `ImageFormatSettings`.
With this, we can also remove these "known failures" from the test
introduced in 4032b853c3.
Pull Request: https://projects.blender.org/blender/blender/pulls/135238
Float->byte rendered image dithering uses triangle noise algorithm. Keep
the algorithm the same, just make some improvements and fix some issues:
1) The hash function for noise was using "trig" hash from "On generating
random numbers" (Rey 1998), but that is not a great quality hash, plus it
can produce very different results between CPUs/GPUs. Replace it with
"iqint3" (recommended by "Hash Functions for GPU Rendering", JCGT 2020),
which is same performance on GPU, faster on CPU, and much better quality.
This is the same hash as Cycles already uses elsewhere. Also it is purely
integer based, so exactly the same results on all platforms.
2) For the above point, replace `dither_random_value` to take integer
pixel coordinates and adjust calling code accordingly. Some previous
callers were (accidentally?) passing integer coordinates already. Other
places actually get a tiny bit simpler, since they now no longer need an
extra multiplication.
3) The CPU dithering path was wrongly introducing bias, i.e. making the
image lighter. The CPU path also needs dither noise to be in [-1..+1]
range (not [-0.5..+1.5]!) just like GPU path does, since the later
float->byte conversion already does rounding.
4) The CPU dithering path was using thread-slice-local Y coordinate,
meaning the dithering pattern was repeating vertically. The more CPU cores
you use, the worse the repetition.
5) Change the way that uniform noise is converted to triangle noise.
Previous implementation was based on one shadertoy from 2015, change it
to another shadertoy from 2020. The new one fixes issues with the old way,
and it just works on the CPU too, so now both CPU and GPU code paths are
exactly the same.
6) Cleanup: remove DitherContext, just a single float is enough
Performance and image comparisons in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/135224
Currently, there is no way to call the sculpt.mask_by_color operator
from the python API without simulating mouse events. This makes writing
python tests harder than it needs to be.
This commit does the following:
* Adds an exec callback for the mask_by_color operator.
* Adds new `location` property, an int array defined in region space
coordinates to represent the mouse location.
* Extracts logic into a helper function so that the `invoke` and `exec`
paths are functionally equivalent.
Pull Request: https://projects.blender.org/blender/blender/pulls/134964
This applies to modifiers, constraints and shape keys.
Any driver on such data was not removed with it,
leaving invalid drivers on objects.
With this patch, the drivers are removed, but animation is left untouched.
This is because animation might be reused somewhere else and we don't
want to introduce potential side effects there.
This also adds unit tests for the fixed cases
Pull Request: https://projects.blender.org/blender/blender/pulls/134511
Glossy light path tests are unexpectedly failing on build bot.
My current guess is that something changed between when the reference
images were made and when the tests were committed.
While an investigation into what's causing it is going on, these tests
have been temporarily added to the blocklist to avoid unexpected
failures for other developers.
This commit adds tests for the outputs of the light path node.
This include many typical tests (E.g. Changing the colour of a material
based on if it's a camera ray or not) along with some "unusual" tests.
Examples include:
- Testing many of the light path node outputs on lights.
- This includes "analytical" lights and mesh lights, which can behave
differently depending on if Next Event Estimation or forward path
tracing occurs.
- Adding extra objects using ray portal BSDFs and transparent BSDFs
just to double check they don't introduce their own issues.
Ref: blender/blender-test-data!55
Previously, when a file output test failed, all images within the same
test case were updated, even images that did not cause the test to fail.
This patch only updates changed/removed images so when the test is run
using `BLENDER_TEST_UPDATE=1 ctest -R compositor_cpu_file_output` git
will only show the modified, added or removed images
Pull Request: https://projects.blender.org/blender/blender/pulls/134852
Adds a new CMake option so that these tests can be run independently of
other tests, and so that existing tests that use WITH_GPU_RENDER_TESTS
are not forced to run these sculpt tests.
Pull Request: https://projects.blender.org/blender/blender/pulls/134893
`oiiotool` diff generation is single-threaded and can become a
bottleneck on fast to render tests.
This PR generates diffs in parallel using the `multiprocessing` module.
Overlay tests (local): 90s -> 30s
buildbot +gpu:
macOS: 2020s -> 1808s
Linux: 1901s -> 1327s
Pull Request: https://projects.blender.org/blender/blender/pulls/134938
This commit adds a test for the light falloff node on many different
objects. Examples include point lights, sun lights, mesh lights,
background lights, and direct visibility to camera.
Ref: blender/blender-test-data!56
This adds support for Overlay tests.
There are some differences with how we handle tests for other engines:
- The renders are captured using `bpy.ops.render.opengl()`, but this
won't work on our GPU build bots.
- A single blend file can run multiple tests by outputting a txt list
with the test names.
- Each overlay test blend file requires a matching script file with
the same name inside `tests/python/overlay/`.
- To reproduce a specific test state you can run
`blender "(...)/tests/data/overlay/<test>.blend" -P "(...)/tests/python/overlay/<test>.py" -- --test <test-number>`.
Note:
The current test permutations are WIP, so reference images are not
committed to the data repo for now.
Pull Request: https://projects.blender.org/blender/blender/pulls/133879
The compositor previously overloaded the vector type to represent
multiple dimensions that are always stored in a 4D float vector. This
patch introduce a dedicated type for float4, leaving the vector type to
always represent a 3D vector, which will be done in a later commit.
This is not exposed to the user as a separate socket type with a
different color, it is only an internal type that uses the same vector
socket shape and color.
Since the vector socket represents both 4D and 3D vectors, code
generally assumes that such sockets represents 3D vectors, and the
developer is expected to set it to a 4D vector if needed in the node
operation constructor, or use the newly added skip_type_conversion flag
for nodes that do not care about types, like the File Output node.
Though this should be redundant once we add a dimension property for
vector sockets.
Pull Request: https://projects.blender.org/blender/blender/pulls/134486
Expose the convenience function `blender::animrig::action_fcurve_ensure()`
to RNA as `Action.fcurve_ensure_for_datablock(...)`.
The function requires that the Action is already assigned to the
data-block. It then takes care of slot assignment / creation, as well as
the creation of a layer and a keyframe strip.
This function call:
```python
fcurve = action.fcurve_ensure_for_datablock(ob_cube, "location", index=2)
```
effectively performs this logic:
```python
# Ensure the slot exists and is assigned:
slot = ob_cube.animation_data.slot
if not slot:
slot = find_slot_for_keying(action)
if not slot:
slot = action.slots.new(ob_cube.name)
ob_cube.animation_data.slot = slot
# Ensure a layer exists:
if action.layers:
layer = action.layers[0]
else:
layer = action.layers.new("Layer")
# Ensure a keyframe strip exists:
if layer.strips:
strip = layer.strips[0]
else:
strip = layer.strips.new('KEYFRAME')
# Ensure the channelbag exists:
channelbag = strip.channelbag(slot, ensure=True)
# Ensure the F-Curve exists:
fcurve = channelbag.fcurves.find("location", index=1)
if not fcurve:
fcurve = channelbag.fcurves.new("location", index=1)
```
Here `find_slot_for_keying()` represents the logic that's also used when
creating keys via the user interface or the `bpy_struct.keyframe_insert()`
function.
Pull Request: https://projects.blender.org/blender/blender/pulls/134686
In a recent commit (1), a bug was fixed where the generated texture
coordinates on volumes in Cycles with OptiX OSL was incorrect.
Due to this fix, OptiX OSL now passes render tests in scenes that use
that feature, so this commit enables those tests on that platform.
(1) 0177537c9a
Pull Request: https://projects.blender.org/blender/blender/pulls/134629
The patch adds a simple framework to test the File Output Node in the compositor. The main difference to the existing `render_test.py` framework is that multiple output images are supported. Edge cases such as empty output or too many outputs are supported as well.
Tests can be run like other compositor tests, e.g. `ctest -R compositor_cpu_file_output --verbose` or `BLENDER_TEST_UPDATE=1 ctest -R compositor_cpu_file_output` to update failing tests.
Sample output:
```
...
119: [ RUN ] Running test single_color...
119: [ PASSED ] Passed
119: [ RUN ] Running test png_passes...
119: [ PASSED ] Passed
119: [ RUN ] Running test mixed...
119: [ FAILED ] Test directory /home/guest/blender-git/blender/tests/data/compositor/file_output/mixed does not exist
119: [ RUN ] Updating test mixed...
119: [ RUN ] Running test no_files...
119: [ PASSED ] Passed
...
```
Parent task: https://projects.blender.org/blender/blender/issues/125893
Pull Request: https://projects.blender.org/blender/blender/pulls/133663
* Adds new entry into python CMakeLists.txt for running these tests
* Adds `sculpt_brush_render_tests.py` as the report runner and
test data initializer for the sculpt tests.
This commit adds the ability to do render tests with the Draw brush in
Sculpt mode on a specified mesh by specifying and performing a stroke in
area-space coordinates.
Like other render tests, these tests map a single .blend file to a
single reference image. Currently we test the following cases:
* A "base" mesh.
* A mesh with a Subdiv modifier added but not applied to it.
* A mesh with a basis & relative shape key added.
* A mesh with the multiresolution modifier added.
The associated reference image used is 200x200 pixels, in testing
with the draw brush, even this small resolution was able to detect
differences in detail caused by major regressions.
In total, the new files in the associated assets repository sum up
to roughly 4.5 MB.
Other than the mesh and modifiers, each of the files also contains a
scene with a camera, with workbench settings set to use a matcap for
the final rendering to better highlight curvature differences.
Part of #130772
Pull Request: https://projects.blender.org/blender/blender/pulls/133602
`environment_mirror_ball.blend` and `image.blend` are both
failling because of mipmap/anisotropic filtering differences
on apple silicon.
The volume tests has issues with lightprobe baking.
Blocking them until we have a workaround.
To align better with the pixel and reduce the samples needed.
The paper was using gamma because the jacobian |d_gamma/d_h| approaches
infinity at the boundaries, but it seems that clamping at 0.999 is
enough for numerical stability.
In practice I did not notice a change in the noise level, but it
simplifies the range computation and renders faster due to reduced
sample amount.
Co-authored-by: Olivier Maury <omaury@meta.com>
Ref: !129616
Pull Request: https://projects.blender.org/blender/blender/pulls/134130
This commit adds a test for the outputs of the object info node.
This includes testing on meshes, and testing the random output on
lights, using area lights placed behind glass.
Tests were added for lights as they take a different code path.
And the glass was added so the lights will be visible to the camera in
the EEVEE render engine so this test can be reused when/if EEVEE gets
light nodes support.
Ref: blender/blender-test-data!54
