This replaces the plain texture selector with a proper TemplateID,
resulting in buttons to add a new texture if none is there yet, and if
there is one, there will be the usual conveniece buttons to add a fake
user, create single user copies, ..., as well as the button to go to the
textures tab in the Properties Editor for more fine-grained control over
the texture.
Fixes#126856
Pull Request: https://projects.blender.org/blender/blender/pulls/126890
Previously, the inferencing result was only stored in the socket shape.
However, that was conflicting with experiments where the socket shape and
the field state was not related.
Use snake style naming for all the kernel nodes functions.
Omit kernel prefix in the names since of the using namespace.
Use full forms of the terms
('iter' -> 'iterator', 'ntree' -> 'node_tree', 'rem' -> 'remove', ...).
Pull Request: https://projects.blender.org/blender/blender/pulls/126416
This operator sets the new default group node width (from e842966c5e) based on
the parent group node. This makes it easier to initialize the value. Without
this, one had to create and delete the group node potentially many times to find
a good default width.
Pull Request: https://projects.blender.org/blender/blender/pulls/126239
This adds the ability to customize the default width of a group node that's
created for a node group. This feature works towards the goal of unifying the
features available to built-in nodes and node groups. We often customize the
width of built-in nodes from them to looks slightly better (e.g. to avoid
cut-off labels).
Pull Request: https://projects.blender.org/blender/blender/pulls/126054
This patch introduces a new experimental option for the new CPU
compositor under development. This is to make development easier such
that it happens directly in main, but the compositor is not expected to
work and will probably crash.
Pull Request: https://projects.blender.org/blender/blender/pulls/125960
Previously, values for `ID.flag` and `ID.tag` used the prefixes `LIB_` and
`LIB_TAG` respectively. This was somewhat confusing because it's not really
related to libraries in general. This patch changes the prefix to `ID_FLAG_` and
`ID_TAG_`. This makes it more obvious what they correspond to, simplifying code.
Pull Request: https://projects.blender.org/blender/blender/pulls/125811
This patch adds support for multi-pass compositing for EEVEE. This is
done by copying the passes used by the compositor node tree to the DRW
view data, which can then be accessed by the viewport compositor.
The viewport compositor will fallback to the viewport texture or an
invalid output of the passes were not initialized, this is currently the
case for any render engine that is not EEVEE.
A future optimization that we can do is eliminate the film pass copy
shaders and only copy the data that EEVEE rendered, which can be a
subset of the viewport for border rendering. This is not done at the
moment because not all engines support passes at the moment, so the
compositor expects full viewport passes.
Depends on: #123685, #123817, #123815.
Pull Request: https://projects.blender.org/blender/blender/pulls/123378
This continues the cmake modernization effort and introduces support for
allowing our optional dependencies to integrate properly. TBB is added
here as it's proven troublesome to maintain correctly.
Currently the only Blender project which uses the TBB headers directly
is `blenlib`. However, all downstream projects which require blenlib as
their dependency, and wish to properly make use of its threading
facilities, needed to define various TBB items in their CMake files. Not
only is this unnecessary and arcane, but several projects didn't do this
and ended up not using threading as well as producing ODR violations
along the way[1].
This PR makes TBB a modern dependency and exposes it PUBLIC'ly from
`blenlib`. All downstream projects which depend on blenlib will now
receive everything they require from TBB automatically. This includes
the `WITH_TBB` define, the headers, and the library itself.
[1] blender/blender@05241f47f5
Pull Request: https://projects.blender.org/blender/blender/pulls/124916
This PR removes the "Widget Label" text style, found in Preferences /
Themes / Text Style. This results in both labels and the text found in
input boxes sharing settings. This results in a slight loss of
customization but it isn't that useful to have these things separate
and results in code complication and errors.
Pull Request: https://projects.blender.org/blender/blender/pulls/122898
Multi-layer image passes are missing after dragging and dropping an EXR
into the compositor editor. To fix this, we tag the new nodes as needing
an update due to changed ID.
Pull Request: https://projects.blender.org/blender/blender/pulls/124855
This commit moves generated `RNA_blender.h`, `RNA_prototype.h` and
`RNA_blender_cpp.h` headers to become C++ header files.
It also removes the now useless `RNA_EXTERN_C` defines, and just
directly use the `extern` keyword. We do not need anymore `extern "C"`
declarations here.
Pull Request: https://projects.blender.org/blender/blender/pulls/124469
Centralized method to obtain ScrArea icons. Areas can add an optional
space_icon_get callback to provide an icon that differs by subtype. If
not defined then ED_area_icon will return RNA UI icon, which is correct
in cases without area subtypes.
Pull Request: https://projects.blender.org/blender/blender/pulls/124556
Centralized method to obtain ScrArea names. Areas can add an optional
space_name_get callback to provide a name that differs by subtype. If
not defined then ED_area_name will return RNA UI name, which is correct
in cases without area subtypes. This eliminates the current use of
RNA_property_enum_name_gettexted using a temporary context, which
results in the reported (hard to duplicate) error.
Pull Request: https://projects.blender.org/blender/blender/pulls/124488
The swapping code incorrectly expected the link to have a start and end.
However, this was not necessarily the case when attempting to create
a link from a node to itself. This case has special handling in
`node_link_find_socket`.
This adds support for attaching gizmos for input values. The goal is to make it
easier for users to set input values intuitively in the 3D viewport.
We went through multiple different possible designs until we settled on the one
implemented here. We picked it for it's flexibility and ease of use when using
geometry node assets. The core principle in the design is that **gizmos are
attached to existing input values instead of being the input value themselves**.
This actually fits the existing concept of gizmos in Blender well, but may be a
bit unintutitive in a node setup at first. The attachment is done using links in
the node editor.
The most basic usage of the node is to link a Value node to the new Linear Gizmo
node. This attaches the gizmo to the input value and allows you to change it
from the 3D view. The attachment is indicated by the gizmo icon in the sockets
which are controlled by a gizmo as well as the back-link (notice the double
link) when the gizmo is active.
The core principle makes it straight forward to control the same node setup from
the 3D view with gizmos, or by manually changing input values, or by driving the
input values procedurally.
If the input value is controlled indirectly by other inputs, it's often possible
to **automatically propagate** the gizmo to the actual input.
Backpropagation does not work for all nodes, although more nodes can be
supported over time.
This patch adds the first three gizmo nodes which cover common use cases:
* **Linear Gizmo**: Creates a gizmo that controls a float or integer value using
a linear movement of e.g. an arrow in the 3D viewport.
* **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be
rotated to change the attached angle input.
* **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale.
In the future, more built-in gizmos and potentially the ability for custom
gizmos could be added.
All gizmo nodes have a **Transform** geometry output. Using it is optional but
it is recommended when the gizmo is used to control inputs that affect a
geometry. When it is used, Blender will automatically transform the gizmos
together with the geometry that they control. To achieve this, the output should
be merged with the generated geometry using the *Join Geometry* node. The data
contained in *Transform* output is not visible geometry, but just internal
information that helps Blender to give a better user experience when using
gizmos.
The gizmo nodes have a multi-input socket. This allows **controlling multiple
values** with the same gizmo.
Only a small set of **gizmo shapes** is supported initially. It might be
extended in the future but one goal is to give the gizmos used by different node
group assets a familiar look and feel. A similar constraint exists for
**colors**. Currently, one can choose from a fixed set of colors which can be
modified in the theme settings.
The set of **visible gizmos** is determined by a multiple factors because it's
not really feasible to show all possible gizmos at all times. To see any of the
geometry nodes gizmos, the "Active Modifier" option has to be enabled in the
"Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of
the following is true:
* The gizmo controls an input of the active modifier of the active object.
* The gizmo controls a value in a selected node in an open node editor.
* The gizmo controls a pinned value in an open node editor. Pinning works by
clicking the gizmo icon next to the value.
Pull Request: https://projects.blender.org/blender/blender/pulls/112677
This adds a new `name` member to the `GeometrySet` class. This name can be set
with the new `Set Geometry Name` node. Currently, the name is only used in the
spreadsheet when displaying instances.
The main purpose of this name is to help debugging in instance trees. However, in the
future it may also be used when exporting instance trees or when creating separate
objects from them.
Note, the name is not expected to be unique, it is fully in user control.
Naming geometries is necessary to make the spreadsheet more useful for instances,
because currently the user has no information for which geometry is used by each instance.
We also want to use this name to improve the integration with grease pencil where
sometimes layers become instances with the same name.
Pull Request: https://projects.blender.org/blender/blender/pulls/114910
Also see 06be295946.
These aren't all cases, but a few that I found by addding a static
assert in `MEM_new` so that it fails for trivially constructible types.
This change allows to pass optional freeing and copy callbacks to
functions setting the `func_argN` member of the `uiBut` and `uiBlock`
structs. These callbacks are used to free or duplicate the data stored
in these void pointers.
Defaults are set respectively to `MEM_freeN` and `MEM_dupallocN`, to
match previous hard-coded behavior.
Utils template functions are added to easily generate callbacks to
types that are managed with the `MEM_new`/`MEM_delete` C++-style
allocation, as long as they provide a copy constructor.
Note that this change should be considered as a temporary, transitional
solution. A more robust and future-proof solution is to move towards
more usage of `std::function` for these callbacks, which can then own
and manage their custom data themselves.
NOTE: Had to make `NodeLinkItem` trivial again, by removing its default
values and instead using an 'init' function. Please ensure that the
code area you are using your data with _is_ compatible with c++ memory
handling. UI code generally is not currently.
Calling `MEM_freeN` on data allocated with `MEM_new` is bad, since it
will not call a destructor matching the one invoked as part of
`MEM_new`.
While in practice cases fixed below were 'not a problem' currently, as
they are trivial Cpp types (and therefore their destructor is doing
nothing), `MEM_freeN` has no way to ensure it is dealing with such a
trivial data type, so allowing such mismatch is dirty and dangerous.
Note that almost all fixed cases look more like unintentional mistakes
(mis-usages of `MEM_new` instead of `MEM_cnew`).
NOTE: There is one more (known!) case in the asset code, which fix is
slightly less trivial, and will go through a separate PR.
NOTE: This is a by-product of some work to detect such invalid usages of
`MEM_freeN` on memory chunks allocated with `MEM_new`.
Pull Request: https://projects.blender.org/blender/blender/pulls/123691
Basically this tries to make the API to stop and kill jobs more explicit &
consistent, so intent is expressed clearly & behavior as expected.
- Remove use of the job start callback address as identifier for the job.
6887dea786 already removed this pattern from the jobs system internals, this
commit also removes it from the API.
- Make stop & kill API and implementation consistent. E.g. don't stop/kill jobs
by either owner **or** type/callback in one function, and by owner (if
provided) **and** type/callback in another. Causes some small behavior
changes, documented inline.
- Use the same job type and API for all preview render jobs (change by Brecht).
There doesn't seem to be a need for the separated types, in fact the
separation might have caused some issues earlier (and added code complexity).
- Add/improve function documentation.
This does actually have subtle behavior changes that are known, see PR, but
they were investigated carefully and seem like implementing wanted behavior.
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/123086
Now the `uiBlock` array for node is indexed with `node.index()` instead
of the draw-index which is not as readily available in some cases.
The main alternative would be to create an extra map from node index
to draw-index but that doesn't seem worth it right now.
The fix is to support interleaving the drawing of zones and frames.
The draw order is determined by the width of the zones/frames.
Larger areas are drawn before smaller ones. This makes sure that
everything is as visible as possible.
The zone border outlines are still drawn on top of all frames.
Solving that is technically more challenging, because we don't want
to use transparency for zone backgrounds because that results in
many possible mixed colors which we want to avoid. Fortunately,
drawing the outlines on top seems to be quite useful anyway.
