If a curve was not using U parameter range of 0..1, the importer
did not properly detect whether the "U endpoint" flag should
be set on it. Fixed that, along with test coverage for the case.
This allows to expose these settings in the Performance panel in the
render buttons. Also moves compositor-specific options away from the
generic node tree structure.
For the backwards-compatibility the options are still present in the
DNA for the bNodeTree. This is to minimize the impact on the Studio
which has used the GPU compositor for a while now. They can be
removed in a future release.
There is no functional changes expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/121583
These are really basic testing as well, merely linking or appending the
first collection or object in all processed blendfiles. But it should
help catching 'rare' issues in linking/appending from older blendfiles.
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).
The node uses multiple transform operations, each using its own sampling. Using bicubic sampling in the translate node causes undesired offsets.
These changes were intentional (see test updates in `c4e1be73`), but the offsets were thought to be too small for users to notice.
Pull Request: https://projects.blender.org/blender/blender/pulls/121495
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
Adds a test to validate the import of Mesh attributes for USD.
It reuses the recently added export attribute test file to generate the
USD file to load.
The test validates the current behavior in `main`. Missing data and bugs
are noted in comments and can be addressed afterwards.
Pull Request: https://projects.blender.org/blender/blender/pulls/121327
This patch implements the Fast Gaussian blur mode for the Realtime
Compositor. This is a faster but less accurate implementation of
Gaussian blur.
This is implemented as a recursive Gaussian blur algorithm based on the
general method outlined in the following paper:
Hale, Dave. "Recursive gaussian filters." CWP-546 (2006).
In particular, based on the table in Section 5 Conclusion, for very low
radius blur, we use a direct separable Gaussian convolution. For medium
blur radius, we use the fourth order IIR Deriche filter based on the
following paper:
Deriche, Rachid. Recursively implementating the Gaussian and its
derivatives. Diss. INRIA, 1993.
For high radius blur, we use the fourth order IIR Van Vliet filter based
on the following paper:
Van Vliet, Lucas J., Ian T. Young, and Piet W. Verbeek. "Recursive
Gaussian derivative filters." Proceedings. Fourteenth International
Conference on Pattern Recognition (Cat. No. 98EX170). Vol. 1. IEEE,
1998.
That's because direct convolution is faster and more accurate for very
low radius, while the Deriche filter is more accurate for medium blur
radius, while Van Vliet is more accurate for high blur radius. The
criteria suggested by the paper is a sigma value threshold of 3 and 32
for the Deriche and Van Vliet filters respectively, which we apply on
the larger of the two dimensions.
Both the Deriche and Van Vliet filters are numerically unstable for high
blur radius. So we decompose the Van Vliet filter into a parallel bank
of smaller second order filters based on the method of partial fractions
discussed in the book:
Oppenheim, Alan V. Discrete-time signal processing. Pearson Education
India, 1999.
We leave the Deriche filter as is since it is only used for low radii
anyways.
Compared to the CPU implementation, this implementation is more
accurate, but less numerically stable, since CPU uses doubles, which is
not feasible for the GPU.
The only change of behavior between CPU and this implementation is that
this implementation uses the same radius, so Fast Gaussian will match
normal Gaussian, while the CPU implementation has a radius that is 1.5x
the size of normal Gaussian. A patch to change the CPU behavior #121211.
Pull Request: https://projects.blender.org/blender/blender/pulls/120431
This patch matches the size of the Fast Gaussian mode of blur with the
standard Gaussian mode. The sigma value was computed as half the radius,
while it should be third of the radius, since Blender's Gaussian
function is truncated at 3 of the standard deviation of the unit
Gaussian. The patch include versioning to adjust the size of existing
files.
Pull Request: https://projects.blender.org/blender/blender/pulls/121211
Implement the design discussed in #120384.
This adds two parameters. One for changing the approximation
method, and another to use the thickness from shadow map.
We pack the former in the gbuffer by dividing the 16bits
used for thickness by two and use one bit to store the
method.
The thickness from shadow map is now decoupled from the
light evaluation shader. This makes it more performant and
compatible with ray-tracing. This commit also uses the
same biases as shadow mapping to avoid aliasing artifacts
(fix#119339).
This refactors the light evaluation quite a bit to
remove unused bits bits and make the whole transmission
light evaluation without too much complexity.
Pull Request: https://projects.blender.org/blender/blender/pulls/121171
Add an RNA enum property `AnimData.animation_binding` that lists all the
bindings available in `AnimData.animation`.
The list of bindings is filtered to only contain the bindings suitable
for the animated ID. This prevents assigning a 'camera' binding to a
mesh.
Un-assigning is done via an operator, represented as an 'X' button in
the interface.
The enum property contains up to two special items:
- "New" to create a new binding for the ID.
- "(none/legacy)" to indicate that this ID doesn't have a binding
assigned. This one is conditional, and only appears when it is
necessary.
These two special items are experimental, and mostly exist because we're
still evaluating things and building a better UI. It is intended that
the binding selector will become as close to the ID selector as
possible.
-----------
Note that this PR also contains #121268 as it builds up from that one, and I didn't want to wait with testing on the buildbot until that one lands.
The new Baklava panel:
Pull Request: https://projects.blender.org/blender/blender/pulls/121269
Refuse to set the RNA property `AnimData.animation_binding_handle` when
`AnimData.animation` is nil.
When in a hypothetical future `AnimData.animation` would be set, the
binding handle would be ignored anyway, as it's only meaningful within
the context of a known animation. Refusing to set the binding handle in
cases where it is known to be meaningless may help to find bugs in
Python scripts.
Pull Request: https://projects.blender.org/blender/blender/pulls/121268
Transport rays that enter to another location in the scene, with
specified ray position and normal. This may be used to render portals
for visual effects, and other production rendering tricks.
This acts much like a Transparent BSDF. Render passes are passed
through, and this is affected by light path max transparent bounces.
Pull Request: https://projects.blender.org/blender/blender/pulls/114386
Add an optional keyword argument `keytype` to the
`rna_struct.keyframe_insert()` function.
This makes it possible to set the new key's type. The code for this was
almost all in place, the only thing that was missing was the RNA
wrapper, which is what this commit adds.
Example: `bpy.context.object.keyframe_insert("location",
keytype='JITTER')`
There is no backward compatibility issue here, because the argument is
optional and defaults to the previously hardcoded value of `KEYFRAME`.
Pull Request: https://projects.blender.org/blender/blender/pulls/120578
Due to legacy reasons (`MEdge`), edge calculation was being done with
idea that edges cannot be temporarily copied. But today, edges are just
`int2`, so using `edge *` instead of `edge` actually made things worse.
And since `OrderedEdge` itself is the same thing as `int2`, it does not
make sense to use `Map` for edges. So, now edges are in a hash set.
To be able to take index of edges, `VectorSet` is used.
The only functional change now is that original edges will be reordered
as well. This should be okay just like an unintentional but stable
indices change.
For 2'000 x 2'000 x 2'000 cube edges calculation, change is around
`3703.47` -> `2911.18` ms.
In order to reduce memory usage, a template parameter is added to
`VectorSet` slots, so they can use a 32 instead of 64 bit index type.
Without that, the performance change is not consistent and might not be
better on a computer with more memory bandwidth.
Co-authored-by: Hans Goudey <hans@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/120224
Expand the `AnimData` struct with an `Animation *` + an
`binding_stable_index` field, and properly handle those relations.
This also adds functionality for actually pointing animated IDs to
`Animation` data-blocks, and automatically hooking up the relevant
`Binding`.
The Depsgraph code is extended to take these new relations into account,
but doesn't trigger any animation evaluation yet.
For more info, see #113594.
Pull Request: https://projects.blender.org/blender/blender/pulls/118677
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 patch ports the GPU Vector Blur node to the CPU, which is in turn
ported from EEVEE. This is a breaking change since it produces different
motion blur results that are more similar to EEVEE's motion blur.
Further, the Curved, Minimum, and Maximum options were removed on the
user level since they are not used in the new implementation.
There are no significant changes to the code, except in the max velocity
computation as well as the velocity dilation passes. The GPU code uses
atomic indirection buffers, while the CPU runs single threaded for the
dilation pass, since it is a fast pass anyways. However, we impose
artificial constraints on the precision of the dilation process for
compatibility with the atomic implementation.
There are still tiny differences between CPU and GPU that I haven't been
able to solve, but I shall solve them in a later patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/120135
This patch unifies the Defocus node between the CPU and GPU compositors.
Both nodes now use a variable sized bokeh kernel which is always odd
sized for a center pixel guarantee. Further the CPU implementation now
properly handles half pixel offsets when doing interpolation, and always
sets the threshold to zero similar to the GPU implementation.
This patch unifies the CPU and GPU implementation for the Bokeh Image
node. The bokeh is now evaluated at the center of pixels and allows
different sizes for the output kernel.
it is not clear from which point the `cos_theta_u` should be computed in
volume segment, so the original implementation was mixing the closest point
and the point where the minimal angle is formed.
Use the closest point on segment as a conservative measure.
Pull Request: https://projects.blender.org/blender/blender/pulls/119965
The Sun Beams node is off by half a pixel. That's because we add a half
pixel offset to the initial coordinates, but then sample the texture
with the half pixel. To fix thus, use the texture_bilinear_extend
utility to sample the image, which takes care of the half pixel offset.
The GPU compositor Chroma Key node differs from the reference
implementation. This is caused by a typo, where the acceptance angle was
halved after computing tangent instead of before computing it.
