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
This patch removes the Texture node from the compositor, which was based
on the legacy Internal Textures system in Blender. The main motivation
for removing this node is as follows:
- Procedural texturing nodes that previously existed in shading and
geometry nodes are now supported in the compositor, which cover 95% of
what is previously possible using and even adds new possibilities like
Gabor, Bricks, and various improvements to existing texture types.
- The old texture system did not support GPU evaluation, so it was
always computed and cached on the CPU, which causes bad performance
especially for interactive use in the viewport compositor. While the
new nodes are fully GPU accelerated and do not require any caching.
- The Texture node didn't support Texture nodes, so it was not fully
supported and we so far had a warning about that.
- The general direction in Blender is to remove the old texture system,
and the compositor was one of the last main users of it. 5.0 is thus
the ideal time to remove such use.
- The Texture node was always and still is a source of bugs, since it
relies on proper tagging for cache invalidation and updates, which is
so far not perfect. It also suffers from UI/UX issues, since it needs
to be adjusted from the properties panel, which can break if there are
other texture nodes in the context.
This is a breaking change and no versioning was attempted since:
1. It is impossible to get the same results as before due to the use of
different random number generators, so any versioning would just give us
the general look.
2. The Texture node supports a lot of possible configurations. For
instance, each general texture can have many options for the basis type,
and each basis type might have multiple options. So versioning all of
that will take a lot of time, code, and effort.
Pull Request: https://projects.blender.org/blender/blender/pulls/140545
This new file can parse the file header (first few bytes) as well as the block
headers.
Right now, this is used by two places:
* `blendfile.py` which is used by `blend2json.py`
* `blend_render_info.py`
This new module is shipped with Blender because it's needed for
`blend_render_info.py` which is shipped with Blender too. This makes using it in
`blendfile.py` (which is not shipped with Blender) a bit more annoying. However,
this is already not ideal, because e.g. `blend2json` also has to add to
`sys.path` already to be able to import `blendfile.py`.
This new file could also be used by blender-asset-tracer (BAT).
The new `BlendFileHeader` and `BlockHeader` types may be subclassed by code
using it, because it wants to store additional derived data (`blendfile.py` and
BAT need this).
New tests have been added that check that the file and block header is parsed
correctly for different kinds of .blend files.
Pull Request: https://projects.blender.org/blender/blender/pulls/140341
Text strip had a fixed size buffer of 512 bytes to hold the displayed
text (this can be much fewer actual characters with non-English
languages). Switch to dynamically allocated buffer instead, which can
hold longer text.
In order to support forward/backward compatibility, TextVars continues
to hold the 512 byte buffer in memory. When writing out the .blend file,
dynamic text buffer is copied into the fixed one. If it is longer, the
text is truncated, so opening the .blend file in an older version
will contain the first 512 bytes of the longer text. When reading
existing files without the dynamic text buffer, it is created from the
static buffer. Conceptually this approach is similar to constraints
name length increase PR !137310.
The text strip editing code was switched to operate on the dynamic
buffer, resizing it as needed. seq::CharInfo internal struct was
switched to be more independent of the actual buffer address; now
each char entry just stores an index into the buffer instead of direct
pointer (side effect: makes the struct smaller as well).
Pull Request: https://projects.blender.org/blender/blender/pulls/140733
Multi-bounce was mainly disabled for disk sampling where the probability of
hitting something is relatively low even with high albedo, but this is not so
much an issue with random walk.
This reduces darkening artifacts at the cost of some extra render time. The
difference is mainly visible when using a high radius.
Pull Request: https://projects.blender.org/blender/blender/pulls/140665
This was broken by !138632, the refactor of the microfacet code to no longer
check the "geometric normal", which in reality was the smoothed normal.
Since the logic is now the same for all closure types, it seemed weird that
the light leak only affects Microfacet closures, not Diffuse.
Turns out that for diffuse closures, the relevant paths were rejected by
the initial hemisphere check in the smooth bump terminator code, which also
incorporates the smoothed but non-bump/normal-mapped normal sd->N.
So, we can detect and prevent the new light leaks by extending this check to
all closure types for the eval case. Sampling already has stricter checks,
so this doesn't apply there.
With this change, we can revert the two test cases back to their pre-refactor
version. In hindsight it was a mistake to just shrug off these changes as okay,
I should have looked closer into the difference.
Pull Request: https://projects.blender.org/blender/blender/pulls/140415
Change the maximum data-block name from 64 to 256 bytes by increasing MAX_ID_NAME value.
Also increase a few related non-ID data name max size, essentially the action slots identifiers, as these are the primary key used to match an Action's slot to an ID by name.
Other sub-data (bones, modifiers, etc.) lengths are not modified here, as these can be made actual dynamic strings in the future, while keeping (a reasonable level of) forward compatibility, during the course of Blender 5 release cycles.
Implements #137608.
Co-authored-by: Bastien Montagne <bastien@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/137196
Fix#79163 bug related to the bevel operation producing disconnected UVs for
new bevel faces. This change replaces previous approach using scattered and
selective usage of functions: bev_merge_uvs, bev_merge_edge_uvs and
bev_merge_end_uvs with one coherent technique for all stages of the bevel operation.
It is utilizing a concept of loop (BMLoop) buckets to keep track of UV vertices
that should be merged at the end of bevel operation by a single call to
bevel_merge_uvs function. This approach doesn't touch initial UV position
calculation done by interpolation algorithm in bev_create_ngon function and
keeps the concept of representative faces (called frep, facerep or rep_face in
code) to help decide to which bucket specific loops should be assigned.
This is from PR https://projects.blender.org/blender/blender/pulls/139595,
which has more explanation and discussion.
Fix#79163 bug related to the bevel operation producing disconnected UVs for
new bevel faces. This change replaces previous approach using scattered and
selective usage of functions: bev_merge_uvs, bev_merge_edge_uvs and
bev_merge_end_uvs with one coherent technique for all stages of the bevel operation.
It is utilizing a concept of loop (BMLoop) buckets to keep track of UV vertices
that should be merged at the end of bevel operation by a single call to
bevel_merge_uvs function. This approach doesn't touch initial UV position
calculation done by interpolation algorithm in bev_create_ngon function and
keeps the concept of representative faces (called frep, facerep or rep_face in
code) to help decide to which bucket specific loops should be assigned.
This is from PR https://projects.blender.org/blender/blender/pulls/139595,
which has more explanation and discussion.
