The numeric levels have no obvious meaning. This removes the distinction
between severity and levels, instead there is a single list of named levels
with defined meaning.
Debug means information that's mainly useful for developers, and trace is for
very verbose code execution tracing.
Pull Request: https://projects.blender.org/blender/blender/pulls/140244
* 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
The crash seems to come from libepoxy GL functions pointing to null.
It seems that libepoxy "Automatically initializes as new GL functions are used."
and that to call a function without a GL context bound, the function
must have been called before with a bound context.
This just modifies the scope of the context binding from
DRW_module_exit to RE_engines_exit, which seems the safest solution
for 4.5.
Pull Request: https://projects.blender.org/blender/blender/pulls/141233
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
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
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 is replaced by geometry nodes, where volumes can now be generated from
point clouds and meshes with more control, and more efficient rendering as a
sparse volume.
No backwareds compatibility is provided, as this would be complicated, and
probably this feature was not used much in the past few years.
This node was supported in Cycles only, not by EEVEE.
Pull Request: https://projects.blender.org/blender/blender/pulls/140292
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
This prevents the use of unaligned data types in
vertex formats. These formats are not supported on many
platform.
This simplify the `GPUVertexFormat` class a lot as
we do not need packing shenanigans anymore and just
compute the vertex stride.
The old enums are kept for progressive porting of the
backends and user code.
This will break compatibility with python addons.
TODO:
- [x] Deprecation warning for PyGPU (4.5)
- [x] Deprecate matrix attributes
- [x] Error handling for PyGPU (5.0)
- [x] Backends
- [x] Metal
- [x] OpenGL
- [x] Vulkan
Pull Request: https://projects.blender.org/blender/blender/pulls/138846
Removes various image filtering/mipmapping leftovers from
pre-2.80 days.
Code: removes all mipmap handling from ImBuf (which is about half of
ImBuf struct size), removes now unused "sample procedural texture
with mipmaps" code, now-unused FELINE filter, etc. The osatex
parameter to various CPU texture sampling functions is never
actually used, which means none of the mipmap code was ever executing.
User visible part: there were settings on the legacy Texture data
block (as used by Brushes etc.), under Sampling section: "MIP Map",
"Gaussian Filter", "Filter Type", "Eccentricity", "Minimum Size" --
they had no effect anywhere, so they are gone, and what remains is
only "Interpolation" and "Size".
RNA / Python API part: removes the ImageTexture RNA properties
corresponding to the above: filter_type, use_mipmap, use_mipmap_gauss,
filter_lightprobes, filter_eccentricity, use_filter_size_min.
Pull Request: https://projects.blender.org/blender/blender/pulls/139978
The Cryptomatte pick layer in the compositor is wrongly displayed due to
color management getting applied even though it is non color data. This
is because the non color meta-data member of viewer images was not set
if it was newels created. To fix this, we make sure it gets set in all
code paths for the viewer.
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
e.g. stands for "exempli gratia" in Latin which means "for example".
The best way to make sure it makes sense when writing is to just expand
it to "for example". In these cases where the text was "for e.g.", that
leaves us with "for for example" which makes no sense. This commit fixes
all 110 cases, mostly just just replacing the words with "for example",
but also restructuring the text a bit more in a few cases, mostly by
moving "e.g." to the beginning of a list in parentheses.
Pull Request: https://projects.blender.org/blender/blender/pulls/139596
When using Vulkan HgiOpenGL was still selected. This PR changes the Hgi selectiong
to be based on the active GPU backend.
With this PR the correct Hgi could be selected, this requires the USD/Hydra libs to be
compiled with Vulkan support.
The previous implementation used `HGI_ENABLE_VULKAN` but had an issue:
- Depending on the platform the environment variable was stored inside a global
and initialized when loading blender (even before our main entry point is triggered)
- Storm render engine in Blender has been adapted to do not do any detection.
Ref #133717
Pull Request: https://projects.blender.org/blender/blender/pulls/135780
... 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).
This allows users to implement arbitrary camera models using OSL by writing
shaders that take an image position as input and compute ray origin and
direction.
The obvious applications for this are e.g. panorama modes, lens distortion
models and realistic lens simulation, but the possibilities are endless.
Currently, this is only supported on devices with OSL support, so CPU and
OptiX. However, it is independent from the shading model used, so custom
cameras can be used without getting the performance hit of OSL shading.
A few samples are provided as Text Editor templates.
One notable current limitation (in addition to the limited device support)
is that inverse mapping is not supported, so Window texture coordinates and
the Vector pass will not work with custom cameras.
Pull Request: https://projects.blender.org/blender/blender/pulls/129495
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
To make adding a dependeny on TBB easier.
Additional changes:
* Using LIB for libmv tests, as it now brings in includes
* Removing Eigen header listing in iTaSC
Pull Request: https://projects.blender.org/blender/blender/pulls/136865
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
