This renames the struct `Sequence` to `Strip`.
While the motivation for this partially comes from
the "Sequence Design" #131329, it seems like this
is a good refactor whether the design gets implemented
or not.
The `Sequence` represents what users see as strips in the
VSE. Many places in the code already refere to a `Sequence`
as "strip". It's the C-style "base class" of all strip types.
This also renames the python RNA type `bpy.types.Sequence`
to `bpy.types.Strip` which means that this technically breaks
the python API.
Pull Request: https://projects.blender.org/blender/blender/pulls/132179
This caused build errors on the docs builder, I can't seem to reproduce
locally, so revert for now and have another look at some point in the
future.
Sadly as these changes usually go, this took 5c515e26bb and
2f0fc7fc9f with it as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/132559
Not entirely straightforward, some manual edits were done since when
this library was created, some of the work was already done.
- Remove any bf_imbuf_movie paths from INC
- Add a dependency though LIB when missing
- Add public dependency to bf_imbuf in bf_imbuf_movie since it uses the
imbuf headers in its public headers.
- Fix namespace not to have underscores
context: https://devtalk.blender.org/t/cmake-cleanup/30260
Pull Request: https://projects.blender.org/blender/blender/pulls/132407
This commit exposes the "Quality" option of the Open Image Denoiser
to the user for the denoise node in the compositor.
There are a few quality modes:
- High - Highest quality, but takes the longest to process.
- Balanced - Slightly lower quality, but usually halves
the processing time compared to High.
- Fast - Further reduce the quality, for a small increase in
speed over Balanced.
Along with that there is a `Follow Scene` option which will use the
quality set in the scene settings.
This allows users that have multiple denoise nodes
(E.g. For multi-pass denoising), to quickly switch all nodes between
different quality modes.
Performance (denoising time):
High: 13 seconds
Balanced: 6 seconds
Fast: 5 seconds
Test setup:
CPU: AMD Ryzen 9 5950X
Denoising a 3840x2160 render
---
Follow ups:
Ideally the "Denoise Nodes" UI panel in the render properties panel
would be hidden if the compositor setup does not contain any
denoise nodes.
However implementing this efficiently can be difficult and so it was
decided this task was outside the scope of this commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/130252
Typically we are more flexibl with the attribute domain and type,
especially in the context of color attributes. This node still used
the old "vertex color" concept (only byte colors on the face corner
domain). It should have been updated for color attributes. Now the
nodes uses the attribute API to retrieve the attribute which
automatically interpolates the domain and type.
Also fix the node's use of the active color attribute to use the new
string based system rather than CustomData. It's incorrect to use the
active color rather than the default, but changing that might break
existin files.
Pull Request: https://projects.blender.org/blender/blender/pulls/132149
- All movie related public headers now have MOV_ prefix instead of
IMB_movie_.
- All movie related public functions now have MOV_ prefix as well,
instead of IMB_movie_ or IMB_anim_.
- IMB_anim.hh -> MOV_read.hh (also ImBufAnim -> MovieReader), and
various utility functions not related to playback were split off
into MOV_util.hh.
- Other function name tweaks for clarity, e.g. IMB_suffix_anim
-> MOV_set_multiview_suffix and so on.
- All except one usages of MOV_get_fps (nee IMB_anim_get_fps) were
ultimately just converting returned value into a float. So make
MOV_get_fps just return that directly. For the (exactly just one)
place that needs numerator and denominator, have
MOV_get_fps_num_denom.
- Code comments on the public header functions.
- Removed never-used code paths inside movie timecode proxy building
file.
It might be easier to review each commit separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/132145
Previously, code related to reading/writing movie files via ffmpeg was
scattered around: some under blenkernel, some directly in generic
imbuf headers, some under intern/ffmpeg. Some of the files were named
with not exactly clear names. Some parts not directly related to movies
were including ffmpeg headers directly (rna_scene.cc).
What is in this PR:
Movie and ffmpeg related code is now under imbuf/movie:
- IMB_anim.hh: movie reading, proxy querying, various utility functions.
- IMB_movie_enums.hh: simple enum definitions,
- IMB_movie_write.hh: movie writing functions.
- intern: actual implementation and private headers.
- ffmpeg_compat.h: various ffmpeg version difference handling
utilities,
- ffmpeg_swscale.hh/cc: scaling and format conversion utilities
for ffmpeg libswscale,
- ffmpeg_util.hh/cc: misc utilities related to ffmpeg,
- movie_proxy_indexer.hh/cc: proxies and timecode indexing for movies,
- movie_read.hh/cc: decoding of movies into images,
- movie_write.cc: encoding of images into movies.
- tests: basic ffmpeg library unit tests that previously
lived under intern/ffmpeg.
Interface changes (at C++ level, no Python API changes):
- Mostly just movie related functions that were BKE_ previously, are now IMB_.
- I did one large-ish change though, and that is to remove bMovieHandle
struct that had pointers to several functions. Now that is
IMB_movie_write_begin, IMB_movie_write_append, IMB_movie_write_end
functions using a single opaque struct handle. As a result, usages
of that in pipeline.cc and render_opengl.cc have changed.
Pull Request: https://projects.blender.org/blender/blender/pulls/132074
By now it is just a "compositor", so move the files one folder up.
Things that were under realtime_compositor/intern move into
already existing intern folder.
Pull Request: https://projects.blender.org/blender/blender/pulls/132004
Avoid rebuilding BVH trees when meshes are copied.
Similar to the other uses of the shared cache system,
this can arbitrarily improve performance when meshes
are copied but not deformed and BVH building is the
main bottleneck. In a simple test file I got a 6x speedup.
The amount of code is also reduced and the system is
much simpler overall-- built out of common threading
patterns like `SharedCache` with its double-checked lock.
RAII is used in a few places to simplify memory management
too.
The downside is storing more `SharedCache` items in the
mesh runtime struct. That has a slight cost when copying
a small mesh many times, but we have ideas to improve that
in the future anyway (#104327).
Pull Request: https://projects.blender.org/blender/blender/pulls/130865
The Lighten blend mode is wrong for factors less than 1, as it is
computed as a weighted maximum using the factor as the weight, while it
should be a simple component-wise maximum.
This is correctly implemented for Compositor, EEVEE, and Cycles. But the
render/material implementation is wrong. So we adjust the implementation
to match the correct one.
The Darken counterpart was already fixed in 1dcf956849. While the
lighten was fixed in 8b7b165ad9 among other patches. This just completes
the fix.
Pull Request: https://projects.blender.org/blender/blender/pulls/131242
NOTE: This also required some changes to Cycles code itself, who is now
directly including `BKE_image.hh` instead of declaring a few prototypes
of these functions in its `blender/utils.h` header (due to C++ functions
names mangling, this was not working anymore).
Pull Request: https://projects.blender.org/blender/blender/pulls/130174
When changing render engine, we discard the persistent data
that could be saved for all the current render instance that
exists. This is to save memory for the new renderer.
When doing so while rendering for F12, `engine_depsgraph_free`
is called after waiting for the render to finish. But this
can be called before the renderer destruction and on the main
thread.
Doing so on the main thread means that the `gpu_context` used
by the renderer cannot be bound for the sake of just receiving
the orphan buffers that the depsgraph holds. This is because
only the worker thread can make the gpu context active.
Binding the draw gpu context in this situation avoid all
possible conflict.
This is basically doing exactly what the
`DRW_render_context_enable/disable` function is doing internally
if the render engine gpu context is null.
Pull Request: https://projects.blender.org/blender/blender/pulls/129982
Blender crashes when opening files that invokes the interactive
compositor on file load with a BadAccess X_GLXMakeCurrent error.
This is caused by the same system GPU context being active in two
threads at the same time, which happens when the GPU context for the
compositor is created in the main thread, it is made current during
creation, but it is not reset to the main GPU context of the drawable
because it is null. So when the GPU compositor actually executes, it
makes the GPU context current again but in its own thread, causing a
BadAccess error in X11 and potentially other window systems.
So the root cause is that the drawable is nullptr, and an attempt to fix
this was committed in 0a70360eb6 but was reverted in 98722773da because
it caused serious issue that were not obvious.
This patch attempts another fix by simply releasing the system GPU
context created when calling the RE_system_gpu_context_ensure. This is
more robust anyways because callers do not expect the context to be
bound form an API point of view.
Pull Request: https://projects.blender.org/blender/blender/pulls/129793
Meta-data are missing on Cryptomatte layers in the GPU compositor, so
they do not get saved using the File Output node. This is due to a use
after free error where a temporary string is used in the meta-data
population logic. This is fixed by assigning the string to a temporary
variable instead.
Thanks to Jorn Visser for finding the cause of the issue.
Blender crashes when changing the compositor execution device. That's
because cached resources that were originally computed for CPU are now
being used for GPU and vice versa, which can be unexpected in code that
uses them.
To fix this, we free and recreate the entire compositor context when the
execution device or precision change, because it is much easier and
safer to recreate everything as opposed to trying to update the
necessary resources.
This patch adds support for passes in the new CPU compositor. This
involves rewriting the get_input_texture method into a get_pass methods
that returns a result as opposed to a texture. The result wraps the
cached GPU texture or image buffer depending on the execution device.
The Render Layers node was implemented for CPU execution and a new
utility constructor for the result class was added to determine type and
precision based on GPU texture format. The fallback depth pass that was
retrieved from the viewport frame buffer was removed, as it was a hack
that can no longer be supported due to the use of stencil format.
Pull Request: https://projects.blender.org/blender/blender/pulls/129154
For Texture baking, there is a CPU-bound preparation step needed to
establish a mapping between the Hi-Res and Low-Res Meshes before the
rendering engine can take over and start the bake.
Part of this process is now taking advantage of parallel_for,
speeding up this step of the Bake process for many/large textures almost
linearly to the number of CPU-cores.
Pull Request: https://projects.blender.org/blender/blender/pulls/128964
Blender crashes when using the GPU compositor sometimes. This is because
compositor render data was accessed before it was updated in the
realtime compositor when detecting compositing device. So fix that by
first updating compositor data before calling any context methods.
The Legacy Cryptomatte node doesn't work in GPU execution mode if
Precision is set to Auto. That's because the colors picked from the Pick
layer might be in half precision and thus will not match the colors in
the Cryptomatte layers. This is due to the compositor using the
context's precision for Viewer outputs as opposed to the precision of
the image that actually needs to be viewed in the Viewer node.
To fix this, we set the Viewer node precision to be the precision of its
input, that way, the Cryptomatte pick layer will be output in full
precision as intended.
Pull Request: https://projects.blender.org/blender/blender/pulls/128495
To avoid unnecessary looping over listbase items the function
`BLI_listbase_count_at_most` was used however it resulting in an awkward
expression: `BLI_listbase_count_at_most(list, count + 1) == count`
replace this with `BLI_listbase_count_is_equal_to(list, count)`.
