... if only a single view is enabled
Logic for touching placeholder files in `RE_RenderAnim` uses
`BKE_scene_multiview_filepath_get` (no matter if only a single view is
enabled), but logic in `BKE_image_render_write` falls back to using the
"regular" filepath (once gotten from `BKE_image_path_from_imformat`) if
there are less than two views.
That would also break the behavior of "Skip Overwrite".
Digging in git history is a bit hard, so not exactly sure why this was
added, but this PR changes behavior so that
`BKE_scene_multiview_filepath_get` is always used (even for a single
(non-empty) view. Done by implementing `RE_ResultIsMultiView`
Pull Request: https://projects.blender.org/blender/blender/pulls/138507
This adds basic templating support to render output paths. By putting
"{variable_name}" in the path string, it will be replaced by the named
variable's value when generating the actual output path. This is similar
to how "//" is already substituted with the path to the blend file's
current directory.
This templating system is implemented for both the primary render output
path as well as the File Output node in the compositing nodes. Support
for using templates in other places can be implemented in future PRs.
In addition to the "{variable_name}" syntax, some additional syntax is
also supported:
- Since "{" and "}" now have special meaning, "{{" and "}}" are now
escape sequences for literal "{" and "}".
- "{variable_name:format_specifier}", where "format_specifier" is a
special syntax using "#", which allows the user to specify how numeric
variables should be formatted:
- "{variable_name:###}" will format the number as an integer with at
least 3 characters (padding with zeros as needed).
- "{variable_name:.##}" will format the number as a float with
precisely 2 fractional digits.
- "{variable_name:###.##}" will format the number as a float with at
least 3 characters for the integer part and precisely 2 for the
fractional part.
For the primary render output path: if there is a template syntax error,
a variable doesn't exist, or a format specifier isn't valid (e.g. trying
to format a string with "##"), the render that needs to write to the
output path fails with a descriptive error message.
For both the primary and File Output node paths: if there are template
syntax errors the field is highlighted in red in the UI, and a tooltip
describes the offending syntax errors. Note that these do *not* yet
reflect errors due to missing variables. That will be for a follow-up
PR.
In addition to the general system, this PR also implements a limited set
of variables for use in templates, but more can be implemented in future
PRs. The variables added in this PR are:
- `blend_name`: the name of the current blend file without the file
extension.
- `fps`: the frames per second of the current scene.
- `resolution_x` and `resolution_y`: the render output resolution.
Pull Request: https://projects.blender.org/blender/blender/pulls/134860
Like other runtime structs, it doesn't make sense to write this
data to files. And moving it out of DNA to an allocated C++ struct
means we can use other C++ features in it, like the new Mutex
type which I switched to in this commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/138551
This patch adds a new `BLI_mutex.hh` header which adds `blender::Mutex` as alias
for either `tbb::mutex` or `std::mutex` depending on whether TBB is enabled.
Description copied from the patch:
```
/**
* blender::Mutex should be used as the default mutex in Blender. It implements a subset of the API
* of std::mutex but has overall better guaranteed properties. It can be used with RAII helpers
* like std::lock_guard. However, it is not compatible with e.g. std::condition_variable. So one
* still has to use std::mutex for that case.
*
* The mutex provided by TBB has these properties:
* - It's as fast as a spin-lock in the non-contended case, i.e. when no other thread is trying to
* lock the mutex at the same time.
* - In the contended case, it spins a couple of times but then blocks to avoid draining system
* resources by spinning for a long time.
* - It's only 1 byte large, compared to e.g. 40 bytes when using the std::mutex of GCC. This makes
* it more feasible to have many smaller mutexes which can improve scalability of algorithms
* compared to using fewer larger mutexes. Also it just reduces "memory slop" across Blender.
* - It is *not* a fair mutex, i.e. it's not guaranteed that a thread will ever be able to lock the
* mutex when there are always more than one threads that try to lock it. In the majority of
* cases, using a fair mutex just causes extra overhead without any benefit. std::mutex is not
* guaranteed to be fair either.
*/
```
The performance benchmark suggests that the impact is negilible in almost
all cases. The only benchmarks that show interesting behavior are the once
testing foreach zones in Geometry Nodes. These tests are explicitly testing
overhead, which I still have to reduce over time. So it's not unexpected that
changing the mutex has an impact there. What's interesting is that on macos the
performance improves a lot while on linux it gets worse. Since that overhead
should eventually be removed almost entirely, I don't really consider that
blocking.
Links:
* Documentation of different mutex flavors in TBB:
https://www.intel.com/content/www/us/en/docs/onetbb/developer-guide-api-reference/2021-12/mutex-flavors.html
* Older implementation of a similar mutex by me:
https://archive.blender.org/developer/differential/0016/0016711/index.html
* Interesting read regarding how a mutex can be this small:
https://webkit.org/blog/6161/locking-in-webkit/
Pull Request: https://projects.blender.org/blender/blender/pulls/138370
* Remove `DEG_get_evaluated_object` in favor of `DEG_get_evaluated`.
* Remove `DEG_is_original_object` in favor of `DEG_is_original`.
* Remove `DEG_is_evaluated_object` in favor of `DEG_is_evaluated`.
Pull Request: https://projects.blender.org/blender/blender/pulls/138317
Ref: #132179
Renames:
- `Editing.act_seq` -> `Editing.act_strip`
- `SequenceModifierData` -> `StripModifierData`
- Its member `mask_sequence` is now `mask_strip`.
- `MetaStack.parseq` -> `MetaStack.parent_strip`
- Remaining function names/parameters that were not dealt with in #132748
- Various references to `seq` or `sequence` throughout code and docs when
referring to a strip
Also moves `_get` to the end of the renamed function names where
applicable for standardization (unless "by" or "from" are used).
There should be no changes to current behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/138077
Blender crashes if the compositor runs from the render pipeline while
the node tree is being drawn. That's because the render pipeline
adjusting the original node tree by calling ntreeCompositTagRender from
a different thread during compositor evaluation, which is unsafe while
the node tree is being drawn on the main thread.
ntreeCompositTagRender seems to update Composite and Texture nodes, but
they don't have update function, so it seems to do nothing in those
cases. It also updates nodes that reference the scene, like the Render
Layers and Cryptomatte nodes, but this seems to be already done in other
places like do_render_compositor_scenes and ntreeCompositUpdateRLayers.
Furthermore, in one of the calls in the render pipeline, it does raw
pointer comparison with the evaluated scene, so the comparison fails and
it does nothing.
Considering the above, it seems this can be omitted from the render
pipeline code.
Pull Request: https://projects.blender.org/blender/blender/pulls/138087
This PR adds Grease Pencil type filter in the view layer, so users can
control whether Grease Pencil objects should be rendered or not. When
the option is turned off, Grease Pencil rendering is skipped.
Pull Request: https://projects.blender.org/blender/blender/pulls/137667
Previously spell checker ignored text in single quotes however this
meant incorrect spelling was ignored in text where it shouldn't have
been.
In cases single quotes were used for literal strings
(such as variables, code & compiler flags),
replace these with back-ticks.
In cases they were used for UI labels,
replace these with double quotes.
In cases they were used to reference symbols,
replace them with doxygens symbol link syntax (leading hash).
Apply some spelling corrections & tweaks (for check_spelling_* targets).
The interactive compositor crashes if the scene resolution is changed
after rendering. That's because the compositor queries its render size
from the scene directly, which might be different from the size that was
already rendered.
To fix this, the compositor should use the size of the existing render
result if available, while it should fallback to the scene resolution.
Pull Request: https://projects.blender.org/blender/blender/pulls/137674
Note that moving to the templated versions of array allocation functions
in [0] caused integer overflow regressions because multiplying by the
`sizeof(type)` caused the following values to be cast to a size_t.
[0]: e85ebb24fe
Add a "Pixel Density" sub-panel to render output settings which
can be used to set the density (as pixels per inch for example).
This is then written to images that support pixel density.
Details:
- The scene has two values a PPM factor and a and base unit.
- The base unit defaults to pixels per inch as this is the most
common unit used.
- Unit presets for pixels per inch/centimeter/meter are included.
- The pixel density is stored in the render result & EXR cache.
- For non 1:1 aspect renders, the density increases on the axis
which looks "stretched", so the PPM will print the correct
aspect with non-square pixels.
Ref !127831
This replaces the deprecated DrawData mechanism by the
usage of the update timestamp `last_update`.
The compositor keeps the `last_update` value of the cached ID
and compares it with the value on the ID at the time of evaluation.
Rel #134690
Pull Request: https://projects.blender.org/blender/blender/pulls/134878
This refactor part of `draw_manager_c.cc` to make it more understandable
and less bug prone.
- Splits the context handing to `draw_gpu_context.cc`
- Rename `draw_manager_c.cc` to `draw_context.cc`
- Merge `DRWContextState` into `DRWContext`
- Merge lots of static functions into `DRWContext` to avoid global access
- Deduplicate code between entry point functions
- Move context init logic to `DRWContext` constructor
- Move resource init logic to `DRWContext::acquire_data`
- Move extraction `TaskGraph` out of `DRWContext`
- Reduce / centralize complexity of enabling draw engines
- Reduce the amount of `drw_get` calls
- Remove unused code
Pull Request: https://projects.blender.org/blender/blender/pulls/135821
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/135813
Since the introduction of e53ac805af, viewer and previews were not
computed when rendering, because we assumed those would only be useful
during interactive compositing. But we received multiple reports that
this is broken. So users generally expect rendering to compute viewers
and previews.
This patch makes a distinction between background rendering and F12
renders, where the latter computes viewer and previews. This should not
have significant effect on the render time, because typically viewer
results are already computed as part of computing composite results.
Pull Request: https://projects.blender.org/blender/blender/pulls/135723
This PR creates 2 namespaces for VSE code:
- `blender::seq` for sequencer core code
- `blender::ed::vse` for editor code
These names are chosen to not be in conflict with each other.
No namespace was used for RNA.
Finally, file `BKE_sequencer_offscreen.h` was moved from BKE to sequencer.
Pull Request: https://projects.blender.org/blender/blender/pulls/135500
The offset calculation would overflow inside `ibuf_get_color` given the
incoming arguments and image size.
Another similar problem, found from quick inspection, would occur inside
`ibuf_get_color_clip` as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/135476
The general idea is to keep the 'old', C-style MEM_callocN signature, and slowly
replace most of its usages with the new, C++-style type-safer template version.
* `MEM_cnew<T>` allocation version is renamed to `MEM_callocN<T>`.
* `MEM_cnew_array<T>` allocation version is renamed to `MEM_calloc_arrayN<T>`.
* `MEM_cnew<T>` duplicate version is renamed to `MEM_dupallocN<T>`.
Similar templates type-safe version of `MEM_mallocN` will be added soon
as well.
Following discussions in !134452.
NOTE: For now static type checking in `MEM_callocN` and related are slightly
different for Windows MSVC. This compiler seems to consider structs using the
`DNA_DEFINE_CXX_METHODS` macro as non-trivial (likely because their default
copy constructors are deleted). So using checks on trivially
constructible/destructible instead on this compiler/system.
Pull Request: https://projects.blender.org/blender/blender/pulls/134771
The compositor backdrop is still visible even after a new completely
different file is loaded. This is because compositor contexts cache
things like the backdrop, and contexts are stored on interactive
compositor renders, which are not freed until Blender is closed. To fix
this, we cleanup the interactive compositor renders that were created
upon file load.
Pull Request: https://projects.blender.org/blender/blender/pulls/135390
The RE_render_result_rect_from_ibuf function (used only by VSE) was
allocating memory for the render result, clearing it to zero and
immediately overwriting it with the image pixel data. Remove the
"clear to zero" part.
Rendering a 1920x1080 resolution movie with VSE (using float
pixel data), average RE_render_result_rect_from_ibuf time goes from
6.8ms down to 3.8ms
Pull Request: https://projects.blender.org/blender/blender/pulls/135170
There's no point in having non-threaded image color space conversion functions.
So merge the threaded and non-threaded functions and clarify names while at it:
- IMB_colormanagement_transform & IMB_colormanagement_transform_threaded
-> IMB_colormanagement_transform_float
- IMB_colormanagement_transform_byte & IMB_colormanagement_transform_byte_threaded
-> IMB_colormanagement_transform_byte
- IMB_colormanagement_transform_from_byte & IMB_colormanagement_transform_from_byte_threaded
-> IMB_colormanagement_transform_byte_to_float
These places were doing single-threaded colorspace conversion previously, and
thus now are potentially faster:
- IMB_rect_from_float (used in many places)
- EXR image "save as render" saving (image_exr_from_scene_linear_to_output)
- Object baking (write_internal_bake_pixels, write_external_bake_pixels)
- General image saving, clipboard copy, movie preparation
(IMB_colormanagement_imbuf_for_write)
- Linear conversion when reading HDR images/movies
(colormanage_imbuf_make_linear)
- EXR multi-layer conversion (render_result_new_from_exr)
For one case I benchmarked, which is to render out a 2D stabilized 10 bit input
movie clip out of VSE, the total render time went from 49sec down to 44sec
(Ryzen 5950X), one of the single-threaded parts was the colorspace conversion
in the movieclip code.
Pull Request: https://projects.blender.org/blender/blender/pulls/135155
The compositor previously overloaded the vector type to represent
multiple dimensions that are always stored in a 4D float vector. This
patch introduce a dedicated type for float4, leaving the vector type to
always represent a 3D vector, which will be done in a later commit.
This is not exposed to the user as a separate socket type with a
different color, it is only an internal type that uses the same vector
socket shape and color.
Since the vector socket represents both 4D and 3D vectors, code
generally assumes that such sockets represents 3D vectors, and the
developer is expected to set it to a 4D vector if needed in the node
operation constructor, or use the newly added skip_type_conversion flag
for nodes that do not care about types, like the File Output node.
Though this should be redundant once we add a dimension property for
vector sockets.
Pull Request: https://projects.blender.org/blender/blender/pulls/134486
This patch removes the compositor texture pool implementation which
relies on the DRW texture pool, and replaces it with the new texture
pool implementation from the GPU module.
Since the GPU module texture pool does not rely on the global DST, we
can use it for both the viewport compositor engine and the GPU
compositor, so the virtual texture pool implementation is removed and
the GPU texture pool is used directly.
The viewport compositor engine does not need to reset the pool because
that is done by the draw manager. But the GPU compositor needs to reset
the pool every evaluation. The pool is deleted directly after rendering
using the render pipeline or through RE_FreeUnusedGPUResources for the
interactive compositor.
Pull Request: https://projects.blender.org/blender/blender/pulls/134437
This patch refactors the Result class in the compositor to use
GMutableSpan and std::variant to wrap the result's data. This reduces
the complexity of the code and slightly optimizes performance. This will
also make it easier to add new types and interface with other code like
multi-function procedures.
Pull Request: https://projects.blender.org/blender/blender/pulls/134112
This patch allows the compositor context to specify exactly which
outputs it needs, selecting from: Composite, Viewer, File Output, and
Previews. Previously, the compositor fully executed if any of those were
needed, without granular control on which outputs are needed exactly.
For the viewport compositor engine, it requests Composite and Viewer,
with no Previews or File Outputs.
For the render pipeline, it requests Composite and File Output, with
node Viewer or Previews.
For the interactive compositor, it requests Viewer if the backdrop is
visible or an image editor with the viewer image is visible, it requests
Compositor if an image editor with the render result is visible, it
requests Previews if a node editor has previews overlay enabled. File
outputs are never requested.
Pull Request: https://projects.blender.org/blender/blender/pulls/133960
There is a special case in the compositor code where viewer nodes are
treated as composite nodes. This patch renames relevant methods and
updates comments to clarify this use case.
Pull Request: https://projects.blender.org/blender/blender/pulls/133811
