Different operations may need to lock different part of the interface,
e.g. for rendering, the image editor may still need refreshing while the
interface is locked, but when baking data into a scene, the image editor
needs to be locked because it is not thread safe to get data from a
partially evaluated depsgraph.
This is a better fix on top of 7c8b8b2457
that addresses the root cause with more flexibility for future
operations that requires different interface locking strategy as
well.
Pull Request: https://projects.blender.org/blender/blender/pulls/141866
* Add render category, which is automatically enabled when using -f or -a
command line flags for background rendering.
* Add extra logs to mention scene, view layer and frame ahead of time rather
than including it in every line.
* Remaining time was removed from Cycles, this will be added back for animations
at the render pipeline level.
Pull Request: https://projects.blender.org/blender/blender/pulls/140244
Job names displayed in the status bar were not extracted or
translated. This commit adds a regex to the bl_i18n_utils settings to
detect `WM_jobs_get()`, and the `RPT_` translation macro to translate
the message in the UI.
About 30 new messages are translated.
Reported by Ye Gui in #43295.
This adds support for scene assets.
* Scenes can be marked like any other ID as assets (e.g. by right-clicking on a scene ID selector).
* Scenes will generate previews by rendering the view from the active camera in solid view.
Note that this requires the scene to have an active camera.
* When dragging a scene asset onto anywhere in a window (except the asset browser itself),
it will import the asset (or use the local ID) and set the scene as the active one in the window.
Pull Request: https://projects.blender.org/blender/blender/pulls/141081
This PR adds several more built-in variables for path templates:
- `scene_name`: name of the current scene.
- `camera_name`: name of the current camera.
- `node_name`: only for paths owned by a node; the name of the node.
- `blend_name_lib`: name of the blend file of the ID the path property
is on, sans file extension.
- `blend_dir`: path up to (but not including) the currently open blend
file.
- `blend_dir_lib`: path up to (but not including) the blend file of the
ID the path property is on.
Additionally, adding support for `node_name` required re-thinking the
"path template type" system a bit:
Previously, the the `PropertyPathTemplateType` of a property completely
dictated what variables were made available to it. However, if we stuck
with that system then we would need to split
`PROP_VARIABLES_RENDER_OUTPUT` into two enum items: one for "normal"
render output paths like the one that lives on the `Scene`, and one for
"node" render output paths like the ones on the File Output node.
Instead of doing that, this PR makes `PropertyPathTemplateType` only
responsible for dictating the "purpose-specific" variables. In this
case, render-specific variables like fps, resolution, etc. Then the
availability of variables like `node_name` are instead based on what
owns the path (a node or not, in this case). There are also general
variables, like `blend_name`, that are now available to all path
templates.
(Part of #133001)
Pull Request: https://projects.blender.org/blender/blender/pulls/139438
The issue was that this operator is using the same
path as the viewport display. So the colors are
clamped if the display is not HDR.
This fix is easy now that we have an HDR path for
the viewport display. We just enforce using it
when doing the viewport render preview.
Currently the remove material slot button still appears to be
active while in edit mode. Attempting to use the button will
result in an error "Unable to remove material slot in edit mode."
Solution is to edit poll function to disable/gray out the remove
material slot button while in edit mode similar to other buttons
In the code a check was added for edit mode for the operator
execution as a fix for bug #21822. However this check was never added
to the polling function. This commit adds that check.
Pull Request: https://projects.blender.org/blender/blender/pulls/139660
Previously `blend_name` was using the same path to get its file name
as `//` used. However, the choice of path for `//` seems to be
bespokely chosen at each call site. There may be a logic to it, but
if so it's not immediately clear what it is.
This PR changes `blend_name` to instead always use the currently open
("global") file path, making it well-defined and predictable for
users.
This also prepares better for PR #139438 for 5.0, which adds
`blend_name_lib`, which always uses the blend file that the ID owning
the path is linked from. Over-all this should be much more predictable
and controllable for users.
Pull Request: https://projects.blender.org/blender/blender/pulls/140474
This changes the engine identifier back to `BLENDER_EEVEE`.
We keep the `BLENDER_EEVEE_NEXT` identifier around for
versioning reasons (have to detect when it is the active
engine of a older file).
This also rename a bunch of pannels that were using `next`
in their name.
This is a breaking change for Addons compatibility.
Pull Request: https://projects.blender.org/blender/blender/pulls/140282
This is part of the short term roadmap goal of simplifying the
compositor workflow
(see https://projects.blender.org/blender/blender/issues/134214).
The problem is that many users don't know how to get started with
compositing in Blender, even when they have used Blender for other
areas, e.g. modeling.
Note: although the solution makes compositor node trees reusable
accross blend files, this is a nice side effect and not the main goal
of the PR.
This PR implements a "New" button that creates a new compositing node
tree, and manages trees as IDs. This has following advantages:
- Consistent with other node editors and other parts of Blender,
therefore making it easier to getting started with compositing if users
are familiar with shading or geometry nodes
- Give users the ability to reuse the compositing node tree by linking
or appending it.
Note: The parameter "Use Nodes" is still present in this PR, but will
be removed (in a backward compatible way) in a follow up PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/135223
Comparing the object with "edit_object" isn't correct as
multiple objects may be in edit-mode across multiple scenes.
Check the object for edit-mode data instead.
The path templates feature implemented in #134860 highlights path
properties that have syntax errors in red and provides a list of those
errors in the path's tool tip. However, syntax errors are not the only
kind of error.
For example, if given the render output path `//render/{blend_nam}`,
with a typo in the variable `blend_name`, this error is not indicated
until actually trying to render. This is because the path is
*syntactically* correct, and the error is due to `blend_nam` not being
an available variable.
This PR resolves this: paths with path template support now indicate all
errors in the UI, not just syntax errors, with red highlights and a list
of errors in the tool tip.
The primary mechanisms for this are:
- A new function `BKE_build_template_variables_for_prop()`, which takes
an RNA pointer and produces an appropriate template variable map for the
given property, which can then be used to fully validate a path
property's value in the UI code.
- A new enum `PropertyPathTemplateType` has been added to `PropertyRNA`,
which determines what variables should be made available to a property
and how they should be build. This is used by
`BKE_build_template_variables_for_prop()`.
Additionally, the following changes have been made to help ensure that
`BKE_path_apply_template()` and `BKE_path_validate_template()` produce
identical errors:
- Both functions now call into a third static function `eval_template()`
that does the actual work, optionally modifying the input path or not.
- Previously only `BKE_path_apply_template()` had unit tests, but now
the unit tests have been reorganized to simultaneously test both
`BKE_path_apply_template()` and `BKE_path_validate_template()`.
Pull Request: https://projects.blender.org/blender/blender/pulls/138679
Previously there was no mechanism to invalidate scene strip cache, when
changes were made to scene that the strip renders. Because of this, the
cache had to be cleared manually, even for other strips.
Strip invalidation is performed from function
`ED_render_id_flush_update`.
Recalc flags like selection or frame change are ignored as they are
unlikely to influence the rendered image.
When some ID is changed, all scene strips using
`DEGEditorUpdateContext::scene` will be invalidated.
Limitations:
- Because frame change is ignored, changes to physics caches would not
invalidate VSE strips
- Only active scene will be invalidated this way. So if an object is
linked to 2 scenes, inactive scene cache would be invalid
- If animated object is moved, and there is VSE preview to be updated
Scene re-rendering in VSE would cause object to snap to its evaluated
position. This is because scene frame is changed by VSE. Reported in
#139501.
To refresh VSE preview after cache is invalidated, relatively big chunk
of code was copied from `view3d_main_region_listener` to VSE preview
listener. Cases that would not result in visual changes like selection
were excluded.
Fixes#113137.
Pull Request: https://projects.blender.org/blender/blender/pulls/138231
In most cases this is a simple switch for `reinterpret_cast` or
`static_cast`, but for `BKE_paint_brush` and `BKE_paint_eraser_brush`
code is duplicated to avoid a `const_cast`.
Pull Request: https://projects.blender.org/blender/blender/pulls/139119
This PR adds a clear on creation for draw region framebuffers, which
fixes issue https://projects.blender.org/blender/blender/issues/139443.
When using the "Lock Interface" option, redrawing is disabled until the
rendering process has finished. When the GPU driver does not initialize
framebuffer textures with zero, this means that visual corruption can
be perceived when resizing the main window while rendering.
This fix makes sure that framebuffer textures are initialized with zero
on all GPU platforms.
Pull Request: https://projects.blender.org/blender/blender/pulls/139445
Briefly about this change:
- OpenColorIO C-API is removed.
- The information about color spaces in ImBuf module is removed.
It was stored in global ListBase in colormanagement.cc.
- Both OpenColorIO and fallback implementation supports GPU drawing.
- Fallback implementation supports white point, RGB curves, etc.
- Removed check for support of GPU drawing in IMB.
Historically it was implemented in a separate library with C-API, this
is because way back C++ code needed to stay in intern. This causes all
sort of overheads, and even calls that are strictly considered bad
level.
This change moves OpenColorIO integration into a module within imbuf,
next to movie, and next to IMB_colormanagement which is the main user
of it. This allows to avoid copy of color spaces, displays, views etc
in the ImBuf: they were used to help quickly querying information to
be shown on the interface. With this change it can be stored in the
same data structures as what is used by the OpenColorIO integration.
While it might not be fully avoiding duplication it is now less, and
there is no need in the user code to maintain the copies.
In a lot of cases this change also avoids allocations done per access
to the OpenColorIO. For example, it is not needed anymore to allocate
image descriptor in a heap.
The bigger user-visible change is that the fallback implementation now
supports GLSL drawing, with the whole list of supported features, such
as curve mapping and white point. This should help simplifying code
which relies on color space conversion on GPU: there is no need to
figure out fallback solution in such cases. The only case when drawing
will not work is when there is some actual bug, or driver issue, and
shader has failed to compile.
The change avoids having an opaque type for color space, and instead
uses forward declaration. It is a bit verbose on declaration, but helps
avoiding unsafe type-casts. There are ways to solve this in the future,
like having a header for forward declaration, or to flatten the name
space a bit.
There should be no user-level changes under normal operation.
When building without OpenColorIO or the configuration has a typo or
is missing a fuller set of color management tools is applies (such as the
white point correction).
Pull Request: https://projects.blender.org/blender/blender/pulls/138433
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
Added a new operator `OBJECT_OT_material_slot_remove_all`
that removes all materials from the material slots of selected objects
This was inspired by a request proposal on RCS.
Pull Request: https://projects.blender.org/blender/blender/pulls/138402
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
Sort of a followup to d177388979
Resolves the limitation mentioned there "A known limitation with this
will be that changes to dependencies won't be indicated in the brush.
E.g. Changing the texture attached to a brush won't make
the brush be indicated as changed."
Part of #136895
Does not fully fix the report though, seems like deleting/relinking the
brush in `asset_reload` still need to do additional stuff to properly
revert the brush textures.
Pull Request: https://projects.blender.org/blender/blender/pulls/136988
Fixes: #136842, #136645
Caused by 76d6d169ba
When multiple objects are selected to mark as assets, preview generation
job of previous ID in the for loop is cleared by `ED_preview_kill_jobs`
inside `generate_preview`. To fix this, check if `id->preview` exists then
clear the preview job if exists inside the new function
`ED_preview_kill_jobs_for_id`.
Solution proposed by @JulianEisel. I came up with idea to use `wm_job_find`
Pull Request: https://projects.blender.org/blender/blender/pulls/136918
If render engines dont specify `RE_USE_PREVIEW` / `bl_use_preview`, they
wont pass the `ED_check_engine_supports_preview` test.
That is mostly meant to tell blender this engine is capable of
generating (Material) previews and if it isnt, they will skip generating
button previews in `icon_preview_startjob_all_sizes`.
There are already exceptions for type of IDs that can still generate
previews (think Asset previews for Objects or Actions), so the same
exception can be made for Images and Brushes as well (these previews
will just befulled from the Image buffer, that should not rely on the engine
whatsoever). We can also be permissive on Groups (they are treated
similar to Objects).
NOTE: this was reported for the Workbench engine, in another (future)
commit, we might even consider flagging that engine `RE_USE_PREVIEW` as
well (see comments in the PR)?
Pull Request: https://projects.blender.org/blender/blender/pulls/136824
Use enum types for event modifier and types,
`wmEventModifierFlag` & `wmEventType` respectively.
This helps with readability and avoids unintended mixing with other
types. To quiet GCC's `-Wswitch` warnings many `default` cases needed
to be added to switch statements on event types.
Ref !136759
When adding a texture to a brush datablock, currently, the resulting
undo step does not have any effect when undone. This is due to the
texture being added to the linked asset library. As we do not want this
extraneous undo step to be created since it has no effect, this commit
does the following:
* Removes the automatic undo handling with OPTYPE_UNDO
* Manually adds a undo step if the newly created Texture datablock was
not moved to a library.
Pull Request: https://projects.blender.org/blender/blender/pulls/136336
Callbacks: exec invoke & modal now use a typed enum wmOperatorStatus.
This helps avoid mistakes returning incompatible booleans or other
values which don't make sense for operators to return.
It also makes it more obvious functions in the WM API are intended
to be used to calculate return values for operator callbacks.
Operator enums have been moved into DNA_windowmanager_enums.h
so this can be used in other headers without loading other includes
indirectly.
No functional changes expected.
Ref !136227
