| Age | Commit message (Collapse) | Author |
|---|
|
In practice this didn't cause problems, but accessing scripts via
bpy.utils.resource_path('USER') ignores the BLENDER_USER_SCRIPTS
environment variable.
|
|
Add new cavity automasking mode based on local mesh
curvature. Cavity masking is a great way to quickly add
detail in crevices and the like. It's meant to be used
with the Paint brush in color attribute mode. It does
work with other brushes but the results can be unpredictable.
{F13131497}
The old "dirty mask" operator has been replace with a new
"mask from cavity" operator that shares the same code with
cavity automasking.
Differences from the sculpt-dev implementation:
* It uses the word "cavity." When I first implemented
this I wasn't aware
this feature existed in other software (and other
paint modes in Blender),
and for reasons that escape me today I initially
decided to call it a concave or
concavity mask.
* The cavity factor works a bit differently. It's
no longer non-linear and functions as a simple
scale around 0.5f.
* Supports custom curves.
* Supports blurring.
Reviewed By: Julian Kaspar, Jeroen Bakker and Campbell Barton
Differential Revision: https://developer.blender.org/D15122
Ref D15122
|
|
Based on patch by Ankit Meel.
Ref D10877
|
|
This adds path guiding features into Cycles by integrating Intel's Open Path
Guiding Library. It can be enabled in the Sampling > Path Guiding panel in the
render properties.
This feature helps reduce noise in scenes where finding a path to light is
difficult for regular path tracing.
The current implementation supports guiding directional sampling decisions on
surfaces, when the material contains a least one diffuse component, and in
volumes with isotropic and anisotropic Henyey-Greenstein phase functions.
On surfaces, the guided sampling decision is proportional to the product of
the incident radiance and the normal-oriented cosine lobe and in volumes it
is proportional to the product of the incident radiance and the phase function.
The incident radiance field of a scene is learned and updated during rendering
after each per-frame rendering iteration/progression.
At the moment, path guiding is only supported by the CPU backend. Support for
GPU backends will be added in future versions of OpenPGL.
Ref T92571
Differential Revision: https://developer.blender.org/D15286
|
|
This is already the case for most CMake usage.
Although some find modules are an exception to this, as they were
originally maintained externally they use some different conventions.
Also corrected bad indentation in: intern/cycles/CMakeLists.txt
|
|
While both are supported, 'arg' is in more common use so prefer it.
|
|
* Use Python executable from lib folder since it's not installed.
* Make bpy module test work for portable install.
* Disable gtests which don't work with different Python link flags
and shared library locations.
Ref D15957
|
|
autopep8 v1.7 added a space after assert & raise,
remove the braces as they aren't needed.
|
|
PLATFORM_BUNDLED_LIBRARIES gathers shared libraries that will be installed
to the lib/ folder. The Blender executable gets a relative rpath pointing to
this folder as part of the install step.
The build rpath is different and uses absolute paths, so that it works for
executables like tests that are in different locations, and to support the
case where the build and install folders are different.
The system is already used for the OpenMP library on macOS. But on Linux it
will only kick in once we start using shared libraries for dependencies.
This also removes Mesa libraries from the old location, as these would cause
Blender to start with software OpenGL.
Ref T99618
|
|
Currently, the compositor can be disabled using the WITH_COMPOSITOR
build option. Since, we intent to always build the realtime compositor,
we need to make the distinction between both compositors clear.
So this patch renames the option to WITH_COMPOSITOR_CPU. Additionally,
the check for the option was moved inside the compositor modules' own
CMake file in preparation for the realtime compositor code.
Differential Revision: https://developer.blender.org/D15622
Reviewed By: Jeroen Bakker, Ray Molenkamp
|
|
|
|
|
|
Contributed by luzpaz.
Differential Revision: https://developer.blender.org/D15588
|
|
44aa9e40ffe40c0b222c2f4675545a5777e27059
|
|
Part of {T84999}
This patch adds test for
- `dissolve_limited`
- `dissolve_mode`
- `merge_normals`
Updated blend file:
{F13162744}
Reviewed By: zazizizou, mont29
Differential Revision: https://developer.blender.org/D15187
|
|
Reference images in the reference_override_dir will be chosen before
images in reference_dir. This allows platform specific reference
images, with a common base.
Ignored when set to None. The caller is responsible
of setting the reference override dir as the unit test is more aware
what the definition of a platform is.
Patch adds `gpu.platform.device_type_get` function to get the device
type that blender has detected.
Reviewed By: brecht
Maniphest Tasks: T99046
Differential Revision: https://developer.blender.org/D15265
|
|
Add internal function (only used for testing at the moment)
`_bpy._driver_secure_code_test`.
Add test `script_pyapi_bpy_driver_secure_eval` to serves two purposes:
- Ensure expressions that should be insecure remain so when upgrading
Python or making any changes in this area.
- Ensure new versions of Python don't introduce new byte-codes that
prevent existing expressions from being executed
(happened when upgrading from 3.7, see [0]).
[0]: dfa52017638abdf59791e5588c439d3a558a191d
|
|
|
|
Regression caused by the introduction of partial resync in February 2022
(rB1695d38989fd482d3c). Code was missing adding some existing overrides
to the mapping in some specific cases, causing resync to create 'new'
ones instead of re-using existing ones.
This commit also adds a basic resync testcase that illustrates this
issue.
|
|
|
|
This commit adds the ability to test Eevee viewport playback performance tests.
Tests should be placed in `lib/benchmarks/eevee/*/*.blend`. {rBL62962} added
initial test files. See https://wiki.blender.org/wiki/Tools/Tests/Performance how
to set it up.
To record the playback performance the test start the viewport playback, and adds
a post frame change handler.
This handler will go over the next steps:
* Ensures the viewport is set to rendered mode.
* Wait for shaders to be compiled. Utilizes `bpy.app.is_job_running` function when
available (v3.3) to wait for shader compilation to finish. When not available will wait
for one minute.
* Draw several warmup frames
* Record for 10 seconds tracking the number of frames drawn and performance counters.
* When ready print the result to the console. The results will be extracted when the
benchmark has run.
## Example report
```
master v3.0 v3.1 v3.2
T88219 0.0860s 0.0744s 0.0744s 0.0851s
blender290-fox 1.3056s 0.8744s 0.7994s 1.2809s
```
{F13232387}
Reviewed By: brecht, fclem
Maniphest Tasks: T99136
Differential Revision: https://developer.blender.org/D15302
|
|
Differential Revision: https://developer.blender.org/D15304
|
|
When running the render test cases on MacOS/Intel the hair render
test fail. Most likely due to the dense geometry and the low
resolution of the test image.
This patch increases the fail threshold so these tests will pass.
Note that I haven't been able to test whether this is also the case
for Linux/Windows. If that is the case we should remove the platform
specific test.
|
|
Makes the current test cases pass on NVIDIA 1080Ti/515.
The tests still fail on other platforms (AMD, Intel). Some are actual failures.
Other require platform specific reference images.
Original patch provided by Brecht van Lommel.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D15264
|
|
The old text was suggesting to run `BLENDER_TEST_UPDATE=1 ctest` for
failed tests. Now it's more clear that this is for the regeneration of
reference (ground truth) images, and that it will not touch passing test
cases.
It now also mentions to commit the new reference images to SVN, driving
the point home that this is for updating those, and not for making
failing tests succeed in general.
Over-the-shoulder reviewed by: @sergey
|
|
|
|
Test basic Difference operation with both a single Objetc and a
collection of three objects as operands, using BMesh (aka 'FAST') mode.
|
|
It can be assumed that all scripts comply with basic pep8 formatting
regarding white-space, indentation etc.
Also remove note in best practices page & update `tests/python/pep8.py`.
If we want to exclude some scripts from make format,
this can be done by adding them to `ignore_files` in:
source/tools/utils_maintenance/autopep8_format_paths.py
Or using `# nopep8` for to ignore for individual lines.
Ref T98554
|
|
|
|
It appears that Metal and MNEE are still not working.
|
|
|
|
Move MNEE to own kernel, separate from shader ray-tracing. This does introduce
the limitation that a shader can't use both MNEE and AO/bevel, but that seems
like the better trade-off for now.
We can experiment with bigger kernel organization changes later.
Differential Revision: https://developer.blender.org/D15070
|
|
|
|
Regression in tests from [0] tests were written to assume a newline was
added to the result of Text.as_string which is no longer the case.
[0]: f4ff36431ccfac2f0a99fc23c18fe0d9de38b36d
|
|
|
|
Fix parameters used in `self.assertAlmostEqual()` call; the code was
passing the error message to the `places` parameter.
|
|
|
|
|
|
- Add missing doxy-section for Apply Parent Inverse Operator
- Use identity for None comparison in Python.
- Remove newline from operator doc-strings.
- Use '*' prefix multi-line C comment blocks.
- Separate filenames from doc-strings.
- Remove break after return.
|
|
This file was skipped by source/tools/utils/autopep8_clean.py
since it doesn't have a .py extension, running the autopep8 tool
recursively detects Python scripts without extensions.
|
|
|
|
These were easilly missable and took some effort to find why the test
were disabled.
|
|
This is the convention for most parts of Blender Python API.
|
|
Add the ability to get/set the selected text.
**Calling the new methods:**
- `bpy.data.texts["Text"].region_as_string()`
- `bpy.data.texts["Text"].region_from_string("Replacement")`
|
|
This adds support for selective rendering of caustics in shadows of refractive
objects. Example uses are rendering of underwater caustics and eye caustics.
This is based on "Manifold Next Event Estimation", a method developed for
production rendering. The idea is to selectively enable shadow caustics on a
few objects in the scene where they have a big visual impact, without impacting
render performance for the rest of the scene.
The Shadow Caustic option must be manually enabled on light, caustic receiver
and caster objects. For such light paths, the Filter Glossy option will be
ignored and replaced by sharp caustics.
Currently this method has a various limitations:
* Only caustics in shadows of refractive objects work, which means no caustics
from reflection or caustics that outside shadows. Only up to 4 refractive
caustic bounces are supported.
* Caustic caster objects should have smooth normals.
* Not currently support for Metal GPU rendering.
In the future this method may be extended for more general caustics.
TECHNICAL DETAILS
This code adds manifold next event estimation through refractive surface(s) as a
new sampling technique for direct lighting, i.e. finding the point on the
refractive surface(s) along the path to a light sample, which satisfies Fermat's
principle for a given microfacet normal and the path's end points. This
technique involves walking on the "specular manifold" using a pseudo newton
solver. Such a manifold is defined by the specular constraint matrix from the
manifold exploration framework [2]. For each refractive interface, this
constraint is defined by enforcing that the generalized half-vector projection
onto the interface local tangent plane is null. The newton solver guides the
walk by linearizing the manifold locally before reprojecting the linear solution
onto the refractive surface. See paper [1] for more details about the technique
itself and [3] for the half-vector light transport formulation, from which it is
derived.
[1] Manifold Next Event Estimation
Johannes Hanika, Marc Droske, and Luca Fascione. 2015.
Comput. Graph. Forum 34, 4 (July 2015), 87–97.
https://jo.dreggn.org/home/2015_mnee.pdf
[2] Manifold exploration: a Markov Chain Monte Carlo technique for rendering
scenes with difficult specular transport Wenzel Jakob and Steve Marschner.
2012. ACM Trans. Graph. 31, 4, Article 58 (July 2012), 13 pages.
https://www.cs.cornell.edu/projects/manifolds-sg12/
[3] The Natural-Constraint Representation of the Path Space for Efficient
Light Transport Simulation. Anton S. Kaplanyan, Johannes Hanika, and Carsten
Dachsbacher. 2014. ACM Trans. Graph. 33, 4, Article 102 (July 2014), 13 pages.
https://cg.ivd.kit.edu/english/HSLT.php
The code for this samping technique was inserted at the light sampling stage
(direct lighting). If the walk is successful, it turns off path regularization
using a specialized flag in the path state (PATH_MNEE_SUCCESS). This flag tells
the integrator not to blur the brdf roughness further down the path (in a child
ray created from BSDF sampling). In addition, using a cascading mechanism of
flag values, we cull connections to caustic lights for this and children rays,
which should be resolved through MNEE.
This mechanism also cancels the MIS bsdf counter part at the casutic receiver
depth, in essence leaving MNEE as the only sampling technique from receivers
through refractive casters to caustic lights. This choice might not be optimal
when the light gets large wrt to the receiver, though this is usually not when
you want to use MNEE.
This connection culling strategy removes a fair amount of fireflies, at the cost
of introducing a slight bias. Because of the selective nature of the culling
mechanism, reflective caustics still benefit from the native path
regularization, which further removes fireflies on other surfaces (bouncing
light off casters).
Differential Revision: https://developer.blender.org/D13533
|
|
Regression in 265d97556aa0f0f2a0e4dd7584e3b8573bbddd54.
Where iterating directly on a property group failed, e.g.:
`iter(group)`, tests missed this since only `group.keys()`
was checked.
|
|
|
|
|
|
This was temporarily added back as the build-bot was running it.
|
|
Left on by accident but should only be used when debugging output.
|
