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
The derivatives of the normal were simply not computed.
The offsetted normals are computed by perturbating the barycentric
coordinates. At triangle boundaries, the normals are extrapolated,
so discontinuities might be visible.
Currently only supported on triangles.
Pull Request: https://projects.blender.org/blender/blender/pulls/133769
This PR does some changes to the render and compositor tests
- Compositor test will now test all GPU backends that are compiled
- EEVEE/Workbench render tests will move the GPU backend to the front of the
test name (eevee_next_opengl_bsdf)
- Blacklist EEVEE render tests that fail on Vulkan.
Pull Request: https://projects.blender.org/blender/blender/pulls/133981
The general idea is to store an array of (type, data) pointers of all
PointerRNA ancestors of the current one.
This will help solving cases in our code where the owner (or sometimes
even the owner of the owner) of a random PointerRNA needs to be
accessed. Current solution mainly relies on linear search from the owner
ID, which is sub-optimal at best, and may not even be possible in case a
same data is shared between different owners.
This lead to refactoring quite a bit of existing PointerRNA creation code.
At a high level (i.e. expected usages outside of RNA internals):
* Add `RNA_pointer_create_with_parent` and
`RNA_pointer_create_id_subdata` to create RNA pointers with
ancestors info.
* `RNA_id_pointer_create` and `RNA_main_pointer_create` remain
unchanged, as they should never have ancestors currently.
* Add `RNA_pointer_create_from_ancestor` to re-create a RNA pointer
from the nth ancestor of another PointerRNA.
* Add basic python API to access this new ancestors data.
* Update internal RNA/bpy code to handle ancestors generation in most
common generic cases.
- The most verbose change here is for collection code, as the owner of the
collection property is now passed around, to allow collection items to get
a valid ancestors chain.
Internally:
* `PointerRNA` now has an array of `AncestorPointerRNA` data to store
the ancestors.
* `PointerRNA` now has constructors that take care of setting its data for
most usual cases, including handling of the ancestor array data.
* Pointer type refining has been fully factorized into a small utils,
`rna_pointer_refine`, that is now used from all code doing that operation.
* `rna_pointer_inherit_refine` has been replaced by
`rna_pointer_create_with_ancestors` as the core function taking care of
creating pointers with valid ancestors info.
- Its usage outside of `rna_access` has been essentially reduced to custom
collection lookup callbacks.
Implements #122431.
--------------
Some notes:
* The goal of this commit is _not_ to fully cover all cases creating
PointerRNA that should also store the ancestors' chain info. It only
tackles the most generic code paths (in bpyrna and RNA itself mainly).
The remaining 'missing cases' can be tackle later, as needs be.
* Performances seem to be only marginally affected currently.
* Currently `AncestorPointerRNA` only stores PointerRNA-like data.
This will help `StructPathFunc` callbacks to more efficiently generate
an RNA paths when calling e.g. `RNA_path_from_ID_to_property`, but will
not be enough info to build these paths without these callbacks. And some
cases may still remain fuzzy. We'd have to add thinks like a `PropertyRNA`
pointer, and for RNA collection ones, an index and string identifier, to store
a complete unambiguous 'RNA path' info. This is probably not needed, nor
worth the extra processing and memory footprint, for now.
Pull Request: https://projects.blender.org/blender/blender/pulls/122427
Use sub-pixel differentials for bump mapping helps with reducing
artifacts when objects are moving or when textures have high frequency
details.
Currently we scale it by 0.1 because it seems to work good in practice,
we can adjust the value in the future if it turns out to be impractical.
Ref: #122892
Pull Request: https://projects.blender.org/blender/blender/pulls/133991
This allows Python scripts to easily determine what Slot a Channelbag is
for. This is particularly important because we're trying to discourage
the use of Slot handles in the Python APIs, and before this the only
way to identify which Slot a Channelbag was for was via the Channelbag's
`slot_handle` property.
Pull Request: https://projects.blender.org/blender/blender/pulls/134053
Previously it was possible to make the type prefix of a Slot's identifier get
out-of-sync with its actual target ID type, by setting the identifier via
Python.
This PR changes `Slot.identifier` assignment to ensure that the type prefix is
set to match `target_id_type`. This now makes it impossible for the identifier
prefix and `target_id_type` to get out of sync, since this API previously was
the only way to accomplish that.
When the prefix that the user attempts to set doesn't match the `target_id_type`
of the Slot, a warning is issued telling the user about the mismatch and that
the identifier has been set with the correct prefix instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/133983
