This patch integrate the Sun Beams node into the Glare node as a new
mode. This is done because the Sun Beams node is mostly useless on its
own because it does no thresholding or addition, making it very hard to
use. On the other hand, the Glare node already does thresholding and
addition, so Sun Beams fits perfectly in it.
Pull Request: https://projects.blender.org/blender/blender/pulls/141424
Similar to other removed UI layout functions, this removes uiItemEnumO*
functions and replaces them by calling `uiLayout::op` and writing enum
properties to the returned RNA pointer.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/141632
Supporting this on the Metallic BSDF will require some extra work,
and on the Glossy BSDF it doesn't make much sense conceptually
(for that kind of shader setup, we'll want to support layering in SVM),
but Glass BSDF just needs to be hooked up so might as well do that.
Pull Request: https://projects.blender.org/blender/blender/pulls/140832
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
* Remove bke, ed and wm prefixes
* Add prefixes like: geom, object, blend, lib.
* Shorten some category names
* A few log level changes to improve --log-level info output
Pull Request: https://projects.blender.org/blender/blender/pulls/140244
This commit introduces the extension modes to the transform node and
further streamlines the node properties by wrapping all props in a node
storage. Therefore, the interpolation mode has been removed from the
custom properties of the node and moved into the node storage.
Pull Request: https://projects.blender.org/blender/blender/pulls/141487
This is related to #140381, where the symptom of the bug was a crash
caused by an undefined behavior. In that case, setting a valid active
viewer key was the proper fix. However,
`find_active_context_recursive()` could return `nullptr` in theory so
the same problem might occur in the future.
The commit resolves the undefined behavior by avoiding the
dereferencing of a null pointer.
Pull Request: https://projects.blender.org/blender/blender/pulls/141270
Previously in 95259228d9, property names
within geometry nodes panels are trimmed to make it less verbose if the
property name contains the parent panel's name as prefix, this didn't
take into account where property name can be the same as panel name, in
which case there will be an empty property name which is undesired. So
we should not trim the name in this case.
Pull Request: https://projects.blender.org/blender/blender/pulls/141500
"Median" can have:
- a geometrical meaning, as in the median of points in a mesh,
- a statistical meaning, as in the median of a set of values. Used
in node attribute statistics.
This commit adds the specific "NodeTree" translation context to the
latter sense.
Reported by Satoshi Yamasaki in #43295.
"Edges" usually refers to the edges of a mesh. In the context of the
Keying compositing node, it should be the image processing sense of
edges between color areas. This mirrors the singular "Edge", already
similarly disambiguated.
Reported by Satoshi Yamasaki in #43295.
Link items need to be gathered using the same translation context as
the actual enum prop they come from, in this case "Nodetree".
Reported by Ye Gui in #43295.
This node uses the recently-introduced uiLayout API to draw its UI.
This still needs to do manual translation using `IFACE_()`. This
commit adds this macro.
Reported by Ye Gui in #43295.
Previously, if a socket inside a panel has the same name prefix as the
panel name, the panel name will be removed from socket names when
displayed inside nodes, but this is not done when displaying them on the
modifier interface, which is too verbose visually. Now panel names are
removed from these property labels as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/140448
Use `N_` for default labels in case value is invalid.
So no double translation.
Synchronize translation context with related property if exist.
So enum item translated like property with such enum.
Use nodes context for zone labels.
Pull Request: https://projects.blender.org/blender/blender/pulls/138393
This replaces uiItemMContents, uiItemDecoratorR* and
uiItemProgressIndicator API with uiLayout methods following
uiLayout refactors and the Python API.
`eButProgressType` is changed to a typed enum class
`blender::ui::ButProgressType`
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/141189
This is extracted from #140967.
Previously, it was possible to sync a bundle/closure node based on what's linked.
However, it was not possible to detect if the syncing was possible or necessary
in the first place. Knowing this helps building UI features that inform the user
about outdated nodes.
Change `eCustomDataType` to `bke::AttrType` for uses of the attribute
API (the `AttributeAccessor` one anyway). I didn't touch any values that
might be saved in files; those should be handled on a case by case basis.
Part of #122398
Pull Request: https://projects.blender.org/blender/blender/pulls/141301
The boolean modifier Exact solver has a solver option "Materials"
with choices "Index Based" and "Transfer". The former uses
only materials that were in the first operand object/mesh.
The Transfer option copies new materials as needed from other
object/mesh operands and uses those on the pieces of faces from
those operands that survive into the output.
Users very often use boolean to cut away from a main mesh, and
in such cases usually don't care about the materials on the cutter
operand, and don't want materials from them transferred, so the
"Index Based" choice is the default in the modifier.
It was regarded as in important bug/lack that the new Manifold
solver did not have such an option, so this commit adds one.
The Boolean Geometry Node at the moment does not have an option
and always uses the "Transfer" method, for all three solvers.
It is a matter of discussion whether such an option should be added
in the node also, so this commit does not include such a change.
The Manifold solver, up to this point, ignored the material_remaps
argument and relied on the realize_instance code to remap the
materials (it uses the Transfer strategy).
This change overrides that remapping with the explicit mapping
handed in through the API, if the mapping has non-zero size.
Since the old way (ignoring the mapping argument) worked fine for
the Boolean Geometry Node, I changed that code to make the map
have size zero in the node, in the case that the solver is Manifold.
This is a little hacky but I couldn't think of anything much better.
Long term it might be nice to have the internal boolean API not take
in remaps at all, but rather a remapping strategy choice. One thing
that makes that difficult right now is that the modifier can get
materials from either the object or the mesh (at least that used
to be true) and the internal boolean api only knows about meshes.
Another thing that would have made this task easier (for me) would
be to have realize_instances take in a material mapping strategy
as a parameter.
I18n: Translate a few messages
- Translate add-on types in the user preferences.
- Translate a report which uses formatting.
- Do not translate scene names in `sequencer.scene_strip_add` operator
UI.
- Do translate the type of new scene in
`sequencer.scene_strip_add_new` operator.
- Translate Half and Float image format color depth enum items.
- Translate Mix node header with non-color data types.
- Translate sequencer modifiers' names if data translation is enabled.
Most issues reported by Ye Gui in #43295.
Pull Request: https://projects.blender.org/blender/blender/pulls/141145
There were various UI issues with the Translate node that this patch
fixes:
- Periods at the end of descriptions.
- Missing UI name and description for the interpolation.
- Truncated texts.
This patch introduces a new Extension Mode option to the Translate node,
replacing the current repeat option and adding an extra Extend mode when
the nearest boundary pixel is sampled. The option allows choosing from
Zero, Repeat, and Extend for each of the axis independently.
A new generic sample method was added to the Result class for sampling
with arbitrary interpolation and extension modes.
Pull Request: https://projects.blender.org/blender/blender/pulls/140607
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
This patch adds support for the experimental structure types currently
used bu Geometry Nodes. Pixel nodes were declared as function nodes,
which gives dynamic structures for all their sockets. Other nodes now
explicitly declared their inputs as dynamic if not single value, while
the compositor_expects_single_value marker was removed in favor of the
StructureType::Single type.
Pull Request: https://projects.blender.org/blender/blender/pulls/140910
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
Previously, Float2 images were internally stored as either Float3 or
Float4 images due to limitations in the implementation, which no longer
exists. So this patch refactors the compositor code to store Float2
images in actual Float2 containers, which gives better performance and
memory savings.
Some algorithms were adjusted to operate on Float2 instead of Float3 as
was previously the case.
Pull Request: https://projects.blender.org/blender/blender/pulls/140855
This removes the need to deal with void pointers and explicit casts in many
places. Also it simplifies possibly extending what kind of values can be stored
for each socket in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/140844
Previously, there was the issue that `SocketValueVariant` had a constructor that
took a forwarding reference as parameter. This was problematic, because this
could potentially hide copy/move constructors which is not intentional. This
patch makes sure that these special constructors are not overridden and adds two
static utility functions to make sure it's still straight forward to construct
the `SocketValueVariant` on a single line.
Clangd also warned about this case.
Pull Request: https://projects.blender.org/blender/blender/pulls/140842
