This PR removes the "Last Resort" font from the stack. Instead uses a
custom "not def" glyph, defined as an SVG file. This glyph is shown
when requesting a character not found for text inputs, text editor, and
for Sequencer text strips.
Pull Request: https://projects.blender.org/blender/blender/pulls/132032
This PR adds three tests relating to the mask node, which makes a new
mask data block for `node_mask`, creates an invalid input test,
and covers the `fixed/scene` case.
Coverage:
- Function: 88.89% -> 88.89%
- Line: 91.41% -> 94.53%
- Region: 83.33% -> 88.10%
- Branch: 62.50% -> 81.25%
Pull Request: https://projects.blender.org/blender/blender/pulls/142447
Add new "Linear 3D Curves" option in the Curves panel in the render
properties. This renders curves as linear segments rather than smooth
curves, for faster render time at the cost of accuracy.
On NVIDIA Blackwell GPUs, this can give a 6x speedup compared to smooth
curves, due to hardware acceleration. On NVIDIA Ada there is still
a 3x speedup, and CPU and other GPU backends will also render this
faster.
A difference with smooth curves is that these have end caps, as this
was simpler to implement and they are usually helpful anyway.
In the future this functionality will also be used to properly support
the CURVE_TYPE_POLY on the new curves object.
Pull Request: https://projects.blender.org/blender/blender/pulls/139735
Originally reported for ProRes codec, but it affects multiple
other codecs: any format which is read as >= 10bit had the issue.
A regression since 93be12fde0.
The cause of the issue is that movie clip and image data-blocks
did linearization on their side, which was quite hidden to find.
Now the color management is done on the movie reader level.
Additionally, added regression test to catch such issues early
on in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/143435
It allows to implement tricks based on a knowledge whether the path
ever cam through a portal or not, and even something more advanced
based on the number of portals.
The main current objective is for strokes shading: stroke shader
uses Ray Portal BSDF to place ray to the center of the stroke and
point it in the direction of the surface it is generated for. This
gives stroke a single color which matches shading of the original
object. For this usecase to work the ray bounced from the original
surface should ignore the strokes, which is now possible by using
Portal Depth input and mixing with the Transparent BSDF. It also
helps to make shading look better when there are multiple stroke
layers.
A solution of using portal depth is chosen over a single flag due
to various factors:
- Last time we've looked into it it was a bit tricky to implement
as a flag due to us running out of bits.
- It feels to be more flexible solution, even though it is a bit
hard to come up with 100% compelling setup for it.
- It needs to be slightly different from the current "Is Foo"
flags, and be more "Is Portal Descendant" or something.
An extra uint16 is added to the state to count the portal depth,
but it is only allocated for scenes that use Ray Portal BSDF.
Portal BSDF still increments Transparent bounce, as it is required
to have some "limiting" factor so that ray does not get infinitely
move to different place of the scene.
Ref #125213
Pull Request: https://projects.blender.org/blender/blender/pulls/143107
This patch improves the realism of the Fog Glow mode of the Glare node
based on the Photopic model described in:
Physically-Based Glare Effects for Digital Images" by G. Spencer, P.
Shirley, K. Zimmerman, and D. P. Greenberg.
This is a breaking change that can't be versioned, but it is worth it
for the superior realism of the new model.
Pull Request: https://projects.blender.org/blender/blender/pulls/140646
Previously code that was reading Strip data assumed that seqbasep
and channels members would stay at fixed offsets within a struct,
forever into the future. Fix this by inferring their offsets from
the file SDNA data where needed.
Actual Strip DNA layout is not changed in this commit yet.
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/142940
This includes a new list structure type and socket shape, a node
to create lists, a node to retrieve values from lists, and a node to
retrieve the length of lists. It also implements multi-function support
so that function nodes work on lists.
There are three nodes included in this PR.
- **List** Creates a list of elements with a given size. The values
are computed with a field that can use the index as an input.
- **Get List Item** A field node that retrieves an element from a
a list at a given index. The index input is dynamic, so if the input
is a list, the output will be a list too.
- **List Length** Just gives the length of a list.
When a function node is used with multiple list inputs, the shorter
lists are repeated to extend it to the length of the longest.
The list nodes and structure type are hidden behind an experimental
feature until we can be sure they're useful for an actual use case.
Pull Request: https://projects.blender.org/blender/blender/pulls/140679
Use Principled BSDF instead of Diffuse BSDF. This is a breaking change but
likely does not affect many scenes significantly. It adds some specularity
when an object does not have a a material assigned.
Fix#142538
Pull Request: https://projects.blender.org/blender/blender/pulls/142703
HDR video files are properly read into Blender, and can be rendered out
of Blender.
HDR video reading / decoding:
- Two flavors of HDR are recognized, based on color related video
metadata: "PQ" (Rec.2100 Perceptual Quantizer, aka SMPTE 2084) and
"HLG" (Rec.2100 Hybrid-Log-Gamma, aka ARIB STD B67). Both are read
effectively into floating point images, and their color space
transformations are done through OpenColorIO.
- The OCIO config shipped in Blender has been extended to contain
Rec.2100-PQ and Rec.2100-HLG color spaces.
- Note that if you already had a HDR video in sequencer or movie clip,
it would have looked "incorrect" previously, and it will continue to
look incorrect, since it already has "wrong" color space assigned to
it. Either re-add it (which should assign the correct color space),
or manually change the color space to PQ or HLG one as needed.
HDR video writing / encoding"
- For H.265 and AV1 the video encoding options now display the HDR mode.
Similar to reading, there are PQ and HLG HDR mode options.
- Reference white is assumed to be 100 nits.
- YUV uses "full" ("PC/jpeg") color range.
- No mastering display metadata is written into the video file, since
generally that information is not known inside Blender.
More details and screenshots in the PR.
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/120033
Need to ensure that interpolation between neighboring quaternions
takes the shortest path. The Python FBX importer was doing this;
due to oversight was missed in the new importer.
Pull Request: https://projects.blender.org/blender/blender/pulls/142659
Cycles automatically tries to decide if the camera ray should be a
surface or a volume + surface camera ray by checking to see if the
scene contains a volumetric material, and if it does, is it near
where the camera rays are expected to spawn. This step is done
during scene intialization.
With the OSL camera, it is impratical to predict where the
camera rays will spawn during scene intialization, which makes it
impratical to predict if the OSL camera ray will spawn near a
volumetric object. So this commit marks all OSL cameras as
"inside a volume", leading to the spawning of volume + surface camera
rays for OSL cameras while the scene contains a volumetric material.
This leads to increased render times ranging between 1% - 5% in scenes
that use a OSL camera, has a volumetric object in it, and the
volumetric object is far away from the camera. Every other scene should
see no performance impact.
Testing was done on a AMD Ryzen 9 5950X and a NVIDIA GeForce RTX 4090.
Pull Request: https://projects.blender.org/blender/blender/pulls/142036
This fixes the anonymous attribute lifetime inferencing for the closure zone and
the evaluate closure node. It also adds new regression tests for cases where a
closure outputs a field.
Pull Request: https://projects.blender.org/blender/blender/pulls/141925
This fixes 4 bugs all conspiring to make the referenced SubD scenario
quite broken:
- When manually creating a MeshSequenceCache, the reading of edge and
vertex crease data was skipped. Fixed by reading crease data inside
the common `read_mesh` method.
- When importing an Alembic with animated edge or vertex crease data, a
MeshSequenceCache modifier was not being added to the object. This was
due to not checking the relevant crease properties and required adding
a specialized `has_animations` function.
- When importing animated vertex crease data, a duplicate `vertex_crease`
attribute would be created, breaking the animation. Fixed by using the
attribute API rather than custom data.
- The MeshSequenceCache scenario would call into the Alembic Mesh reader
which ended up referencing deallocated stack memory for the
ImportSettings. In release builds this would cause sporadic failures
because the value of `blender_archive_version_prior_44` would be
random. There was already a very old TODO for this and we finally
really needed to address it.
A new test was added which exports animated creases on two meshes and
re-imports them back in. It verifies that each mesh gets a
MeshSequenceCache modifier added and also ensures the values of the
creases are correct for all frames.
Pull Request: https://projects.blender.org/blender/blender/pulls/141646
These two tests cover the extended boundary option for the blur node.
One with single value input and another with variable input.
They mirror the non-extended gaussian tests.
Coverage:
- Function: 86.36% -> 90.91%
- Line: 91.95% -> 96.90%
- Region: 83.51% -> 96.63%
- Branch: 84.00% -> 95.65%
Pull Request: https://projects.blender.org/blender/blender/pulls/141528
In this report, adding the "resolution" attribute didn't clear the
evaluated positions cache. In some cases capturing an attribute on
the mesh might just add the mesh rather than using an attribute
writer.
Previously, we used precomputed Gaussian fits to the XYZ CMFs, performed
the spectral integration in that space, and then converted the result
to the RGB working space.
That worked because we're only supporting dielectric base layers for
the thin film code, so the inputs to the spectral integration
(reflectivity and phase) are both constant w.r.t. wavelength.
However, this will no longer work for conductive base layers.
We could handle reflectivity by converting to XYZ, but that won't work
for phase since its effect on the output is nonlinear.
Therefore, it's time to do this properly by performing the spectral
integration directly in the RGB primaries. To do this, we need to:
- Compute the RGB CMFs from the XYZ CMFs and XYZ-to-RGB matrix
- Resample the RGB CMFs to be parametrized by frequency instead of wavelength
- Compute the FFT of the CMFs
- Store it as a LUT to be used by the kernel code
However, there's two optimizations we can make:
- Both the resampling and the FFT are linear operations, as is the
XYZ-to-RGB conversion. Therefore, we can resample and Fourier-transform
the XYZ CMFs once, store the result in a precomputed table, and then just
multiply the entries by the XYZ-to-RGB matrix at runtime.
- I've included the Python script used to compute the table under
`intern/cycles/doc/precompute`.
- The reference implementation by the paper authors [1] simply stores the
real and imaginary parts in the LUT, and then computes
`cos(shift)*real + sin(shift)*imag`. However, the real and imaginary parts
are oscillating, so the LUT with linear interpolation is not particularly
good at representing them. Instead, we can convert the table to
Magnitude/Phase representation, which is much smoother, and do
`mag * cos(phase - shift)` in the kernel.
- Phase needs to be unwrapped to handle the interpolation decently,
but that's easy.
- This requires an extra trig operation in the kernel in the dielectric case,
but for the conductive case we'll actually save three.
Rendered output is mostly the same, just slightly different because we're
no longer using the Gaussian approximation.
[1] "A Practical Extension to Microfacet Theory for the Modeling of
Varying Iridescence" by Laurent Belcour and Pascal Barla,
https://belcour.github.io/blog/research/publication/2017/05/01/brdf-thin-film.html
Pull Request: https://projects.blender.org/blender/blender/pulls/140944
Detect which volume attributes nodes have a linear mapping to their usage
as density / color / temperature in volume shader nodes, and use stochastic
sampling for them.
Pull Request: https://projects.blender.org/blender/blender/pulls/132908
Stochastically turn a tricubic filter into a trilinear one. This
reduces the number of taps from 64 to 8. It combines ideas from
the "Stochastic Texture Filtering" paper and our previous GPU
sampling of 3D textures.
This is currently only used in a few places where we know stochastic
interpolation is valid or close enough in practice.
* Principled volume density, color and temperature
* Motion blur velocity
On an Macbook Pro M3 with the openvdb_smoke.blend regression test
and cubic sampling, this gives a ~2x speedup for CPU and ~4x speedup
for GPU. However it also increases noise, usually only a little. Equal
time renders for this scene show a clear reduction in noise for both
CPU and GPU.
Note we can probably get a bigger speedup with acceptable noise trade-off
using full stochastic sampling, but will investigate that separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/132908
This is a basic armature deformation test for #141535 using Lattices instead of
Mesh as the target object type. Lattice deformation was briefly broken, which is
caught by this test.
The test adds the general-purpose `unit_test_compare` function to lattice object
data. It only compares lattice point counts and positions for now, more data can
be added later if necessary.
The `MeshTest` class did not support lattice object types yet, so needed some
changes. The Curves case was already supported, but only by full conversion to
mesh data, without actually using the `unit_test_compare` function specific for
curves geometry. This is unchanged, because applying constructive modifiers on
curves does not work. If it were not for this limitation the test could do
actual curves comparisons now.
For lattice support the `MeshTest` class comparison function has been
generalized to all supported object data types. It runs the appropriate
`unit_test_compare` api function and validation where supported (only meshes at
this point).
Pull Request: https://projects.blender.org/blender/blender/pulls/141546
The mesh importer was only checking for animated positions, velocities,
and primvars when determining if a cache modifier needed to be used.
Extend this to crease values (and normals) too.
The added test ensures a base level of coverage here.
Related to: #141633
Pull Request: https://projects.blender.org/blender/blender/pulls/141643
Adds a new file for testing the Multires Apply Base operator.
This is not included with the other modifier tests as it is a bit of an
exception - the modifier is not applied at the end for comparison
between the expected result and actual result.
Pull Request: https://projects.blender.org/blender/blender/pulls/141571
When beveling a vertex with only 2 connected edges, the resulting
geometry was not selected.
Resolve by not only selecting the faces created by the bevel operation,
but also selecting the vertices created.
Note: apply the same change as before,
the LFS data has been manually pushed.
Ref !139691
When beveling a vertex with only 2 connected edges, the resulting
geometry was not selected.
Resolve by not only selecting the faces created by the bevel operation,
but also selecting the vertices created.
Ref !139691
This commit adds a test for the situation in which a AOV pass is used
on a object with a fully or semi-transparent material, either using the
transparent BSDF directly, or mixing it with some other material.
Pull Request: https://projects.blender.org/blender/blender/pulls/141068
It was applying the bounds clamp to each object individually,
which changed spatial relationships between objects. Make the logic
match what used to be done in the Python OBJ importer back in the day.
Pull Request: https://projects.blender.org/blender/blender/pulls/141446
When a paint stroke is executed instead of processed via the modal
handler, prior to this commit, the `paint_brush_update` function was
not called. This method handles initialization of some temporary stroke
data inside `UnifiedPaintSettings`, which is used by dyntopo when
performing edge collapse.
This had the result of causing a divide by 0 with certain uninitalized
settings when using a brush with dyntopo enabled and calling the
operator from the python API (e.g. from unit testing), resulting in
nonsensical deformations.
There are a number of weak points with the current design:
* This issue was only exposed because of the refactor to the
`UnifiedPaintSettings`, indicating that despite these values being
runtime-only, they were still persisted in some cases in .blend files
* The data stored as individual stroke steps is not sufficient to
reconstruct a paint stroke given a list of screen-space locations, and
this data is populated outside of the common `stroke` callbacks.
Both of the above issues are wider reaching than this PR is intended to
fix.
This commit ensures that `paint_brush_update` is called in the `exec`
codepath and updates the related test image.
Pull Request: https://projects.blender.org/blender/blender/pulls/141314
`node_bilateralblur.blend` covered a specific case where the
determinator was a single value. This was renamed to
`node_bilateralblur_det_single_value.blend` and added a single value
input test for the image, and a standard bilateral blur test for cpu/gpu
Coverage:
- Function: 66.67% -> 100%
- Line: 39.10% -> 100%
- Region: 45.71% -> 100%
- Branch: 22.22% -> 88.89%
Pull Request: https://projects.blender.org/blender/blender/pulls/141315
Test for armature deform modifier settings that are not yet covered by other tests:
- Vertex Group vs. Envelope deformation and both combined.
- Vertex group masking ('vertex_group' setting of the modifier)
- Inverted vertex group masking
- Preserve Volume (dual quaternions)
- Vertex Group/Envelope influence mixing (bone option)
- B-Bone deformation
- Multi-modifier mixing
Each case has a new test/expected mesh pair in the modifiers test.
Pull Request: https://projects.blender.org/blender/blender/pulls/141054
In a recent commit (1), light leaking was accidentally introduced on
some objects making use of normal maps (#139870)
This commit adds a test inspired by the file in that report to avoid
issues like this reoccuring in the future.
(1) a6015e1411
Pull Request: https://projects.blender.org/blender/blender/pulls/141065
This addresses issue #120949 to move compositor tests to reflect the
grouping used when adding a new node.
This PR only moves the relevant single tests and their renders into
matching directories. Folders such as 'multi-node setups' and
'pixel nodes' were not changed.
Pull Request: https://projects.blender.org/blender/blender/pulls/139757
Saved files in 4.5 with a compositing node tree containing a Normal
Node with animated 'Dot' input crash in 5.0.
A test case with animated dot and normal inputs was added as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/140908
This test replaces the existing multires modifier test with one that
subdivides the mesh and then compares the result. The existing one has
little purpose, as it applies a modifier with 0 subdivision levels.
Pull Request: https://projects.blender.org/blender/blender/pulls/140567
