I think the special handling for string input node, added in #139478,
was broken by #146033. The early check for src_value (`if (!src_value)`)
caused the string-specific logic to be skipped. This PR moves the
string-specific handling before the src_value check.
Pull Request: https://projects.blender.org/blender/blender/pulls/147697
Support loops at the GLSL level instead of relying on
NOD_shader_nodes_inline.
This improves compilation and runtime performance, avoids causing
recompilations on iteration count changes, and allows supporting
dynamic iteration counts.
(EEVEE-only)
Pull Request: https://projects.blender.org/blender/blender/pulls/145269
Deletion of NTree IDs through custom code path using
`blender::bke::node_tree_free_tree` is fully by-passing standard ID
management code, and was missed when ID::runtime was made an allocated
pointer.
We should really spend some time at some point to get these custom temp
node IDs handling code under control, there should be little to no need
for all this custom allocation and deletion code anymore nowadays.
As discussed in the last geometry nodes workshop, the viewer node now
needs the flexibility to handle new features: bundles, closures, and
lists. This PR takes the opportunity to add support for an arbitrary
number of items. Values are displayed directly in the node are all
displayed in the spreadsheet, where a new tree view allows selecting
which data to view, including nested bundles. Lists, single values,
bundle items, and closure signatures are all visualized in the spreadsheet.
We also prioritize the existing viewer behavior that views a geometry
together with a field, so various special cases are added in the viewer
activation to handle this.
Bundle hierarchies are displayed in the new tree view in the spreadsheet
sidebar. The spreadsheet itself just displays bundle identifiers, types,
and the contained values. Design wise, there might be more integrated
ways to present that hierarchy, but doing it in the tree view is a very
simple starting place.
Interactively added viewer node inputs are now removed automatically
if the link is removed. There is a new "Auto Remove" flag for each input
controlling this behavior. It can't be enabled for all inputs all the time
because then one couldn't e.g. setup the viewer node properly using
a script (which might add a few inputs first and then creates links).
Also when viewer items are added with the plus icon in the sidebar,
they are not automatically removed immediately.
https://code.blender.org/2025/07/geometry-nodes-workshop-july-2025/#view-any-data
Co-authored-by: Hans Goudey <hans@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/144050
This adds a function that can turn an existing `bNodeTree` into an inlined one.
The new node tree has all node groups, repeat zones, closures and bundles
inlined. So it's just a flat tree that ideally can be consumed easily by render
engines. As part of the process, it also does constant folding.
The goal is to support more advanced features from geometry nodes (repeat zones,
etc.) in shader nodes which the evaluator is more limited because it has to be
able to run on the GPU. Creating an inlined `bNodeTree` is likely the most
direct way to get but may also be limiting in the future. Since this is a fairly
local change, it's likely still worth it to support these features in all render
engines without having to make their evaluators significantly more complex.
Some limitations apply here that do not apply in Geometry Nodes. For example,
the iterations count in a repeat zone has to be a constant after constant
folding.
There is also a `Test Inlining Shader Nodes` operator that creates the inlined
tree and creates a group node for it. This is just for testing purposes.
#145811 will make this functionality available to the Python API as well so that
external renderers can use it too.
Left for future work:
* Freestyle modifiers, dynamic paint, legacy texture mapping
* Editor colors: should be changed to sRGB?
* Studio light preferences: also sRGB, though less clear
Pull Request: https://projects.blender.org/blender/blender/pulls/145476
When panels in node groups were introduced, the interface data of a tree was
moved from `tree.inputs_legacy/outputs_legacy` to `tree.tree_interface`. For
forward compatibility, the old interface was still written. Since Blender 4.5
can read the new format and older versions are not able to open files created in
5.0 directly anymore, it's fine to remove this forward-compatibility code now.
Also fixes#145278.
Pull Request: https://projects.blender.org/blender/blender/pulls/145489
Add back custom properties to nodes, and properly expose them in the UI
as such (new 'Custom Properties' panel for nodes in the the Node
Editor).
This shows like any other custom property panel in the UI, in the Node editor:
<img width="424" alt="image.png" src="attachments/adb50815-0db0-447f-ac3b-7860d9a3e3fc">
Although not initially intended for this, nodes 'mixed' IDProperties
were quite widely used by py/extensions developers to store per-node
data.
During the initial IDProperties split between User-defined (aka custom
data) and system-defined (runtime RNA properties), this was not known,
so decision was made to only keep system properties for Nodes. The fact
that these properties were not exposed at all in UI also played a role
in that decision. See also discussions in #141042.
This commit instead splits system properties out into their own new
storage, and keep existing ones for user-defined/custom properties
(as done for other IDProperty owners, like IDs, bones, etc.).
Pull Request: https://projects.blender.org/blender/blender/pulls/145424
This patch turns node Menu options into menu inputs. This patch only
covers node operations like Filter, Distort, and so on. Pixel nodes like
Color Balance, Matte, and so on will be done in a separate patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/144495
Add geometry file import nodes support to the for-each-path logic.
This will make `bpy.data.file_path_map()` report the input files for
OBJ, PLY, etc. import nodes (and any other node that has a string
property of subtype `PROP_FILEPATH`).
Currently this only supports static file paths, so where the file path
is set as the input socket's default value. When the path is
determined via any noodle, this is ignored and the default value is
reported anyway.
This is necessary for the new version of Blender Asset Tracer, which
in turn is needed to resolvestudio/flamenco#104423.
Pull Request: https://projects.blender.org/blender/blender/pulls/144874
Previously, we always just used `int` when dealing with menu values on the C++
side. It's currently the only type where we have the same base type (`int`) for
two different socket types (integer and menu sockets). This has some downsides:
* It requires special cases in some places.
* There is no function from static base type to socket type (which is useful for
some utilities like `SocketValueVariant`).
* It implicitly allows operations on menu values that shouldn't be allowed such
as arithmetic operations and conversions to and from other types.
This patch adds a new `MenuValue` type that is used for menu sockets in Geometry
Nodes and the (CPU) Compositor, clarifying the distinction between integer and
menu values.
Pull Request: https://projects.blender.org/blender/blender/pulls/144476
This patch redesigns the File Output node to provide better UX and UI.
This is mainly achieved by allowing the user to create inputs by
dragging into an Extend socket and adjust existing inputs using the
familiar UI list design available in Blender. Additionally, various UI
changes were done:
- The Use Node Format option was renamed to Override Node Format for
clarity.
- Socket types are now fixed and do not change as new links are made,
allowing users to specify the exact output type and employ implicit
conversion if needed.
- The distinction between images and Multi-Layer EXR was made clearer.
- Final output paths are drawn in the UI to remove guess work.
- The Base Path was split into a Directory and a File Name.
- Panels were added to group options, include a panel for the node
format, items, and item formats.
Pull Request: https://projects.blender.org/blender/blender/pulls/141091
Generally, node names are expected to be unique within a node tree. However,
`ntree_shader_copy_branch` currently does not enforce this for performance
reasons. This was broken by recent changes in 5b73f798d0 and 9fd877e174 which
allows for passing already unique names and identifiers to the node copy
function.
The main problem here was that the `use_unique` parameter of the `node_copy`
function was not well defined. Now, this function is completely removed in favor
of using `node_copy_with_mapping` directly. This also has a new
`allow_duplicate_names` parameter now which makes the expected behavior more
explicit.
Pull Request: https://projects.blender.org/blender/blender/pulls/143951
We generally expect `bNodeTreeRuntime::nodes_by_id` to be valid at all times, so
it also has to have the same order `bNodeTree.nodes`. When freeing a node, the
entire vector set was rebuild currently to ensure that invariant. This leads
O(n^2) behavior when all nodes are freed as is commonly the case with depsgraph
copies etc.
This patch implements an optimization where `nodes_by_id` is not rebuild if only
the last node was removed. In this case, that not can just be popped from
`nodes_by_id` without affecting the order of the other nodes. To use this
optimization, the node tree freeing code now frees nodes in reverse order.
Pull Request: https://projects.blender.org/blender/blender/pulls/143831
This is useful when the src node name is not unique, but the caller can provide
a unique name more efficiently then if the function has to compute the name
automatically.
This removes the "Geometry" part from their name because we want to use them in
other node tree types too (see #141936).
Usually, we don't change idnames because they are the primary identifier of
nodes and is expected to stay the same. Since they are generally not shown to
users (just Python developers), it's also not urgent to change them. However, in
this specific case we have the opportunity to update the idname before the node
becomes an official feature, so it's not as bad to change it.
This patch has full backward compatibility, but no forward compatibility (for
files that used the experimental feature).
Pull Request: https://projects.blender.org/blender/blender/pulls/143823
This is a continuation of #140705. It changes more menu node options to be input
sockets. It also changes the order of the input sockets in a few cases to make
the node look a bit better.
Forward and backward compatibility is preserved.
Pull Request: https://projects.blender.org/blender/blender/pulls/142220
Use `BLI_strncpy_utf8` & `BLI_snprintf_utf8` for fixed size buffers in
DNA and screen data structures such as panels, menus & operators.
This could be considered a fix as copying a UTF8 string into a smaller
buffer without proper truncation can create an invalid UTF8 sequence.
However identifying which of these users are likely to run into would
be time consuming and not especially useful.
This extends the API for bundles in two main ways:
* Adds support for working with paths to reference nested bundles directly.
* Adds support for typed add/lookup, also taking into account implicit conversions.
Some unit tests have been added as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/142942
So far, only node group were able to have menu input sockets. Built-in nodes did
not support them. Currently, all menus of built-in nodes are stored on the node
instead of on the sockets. This limits their flexibility because it's not
possible to expose these inputs.
This patch adds initial support for having menu inputs in built-in nodes. For
testing purposes, it also changes a couple built-in nodes to use an input socket
instead of a node property: Points to Volume, Transform Geometry, Triangulate,
Volume to Mesh and Match String.
### Compatibility
Forward and backward compatibility is maintained where possible (it's not
possible when the menu input is linked in 5.0). The overall compatibility
approach is the same as what was done for the compositor with two differences:
there are no wrapper RNA properties (not necessary for 5.0, those were removed
for the compositor already too), no need to version animation (animation on the
menu properties was already disabled).
This also makes menu sockets not animatable in general which is kind of brittle
(e.g. doesn't properly update when the menu definition changes). To animate a
menu it's better to animate an integer and to drive an index switch with it.
### Which nodes to update?
Many existing menu properties can become sockets, but it's currently not the
intention to convert all of them. In some cases, converting them might restrict
future improvements too much. This mainly affects Math nodes.
Other existing nodes should be updated but are a bit more tricky to update for
different reasons:
* We don't support dynamic output visibility yet. This is something I'll need to
look into at some point.
* They are shared with shader/compositor nodes, which may be more limited in
what can become a socket.
* There may be performance implications unless extra special cases are
implemented, especially for multi-function nodes.
* Some nodes use socket renaming instead of dynamic socket visibility which
isn't something we support more generally yet.
### Implementation
The core implementation is fairly straight forward. The heavy lifting is done by
the existing socket visibility inferencing. There is a new simple API that
allows individual nodes to implement custom input-usage-rules based on other
inputs in a decentralized way.
In most cases, the nodes to update just have a single menu, so there is a new
node-declaration utility that links a socket to a specific value of the menu
input. This internally handles the usage inferencing as well as making the
socket available when using link-drag-search.
In the modified nodes, I also had to explicitly set the "main input" now which
is used when inserting the node in a link. The automatic behavior doesn't work
currently when the first input is a menu. This is something we'll have to solve
more generally at some point but is out of scope for this patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/140705
* 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
Currently, the standard init function is called before socket
declaration, but the contextual init function is called after, which is
problematic if the declaration depends on the initialization step. This
patch moves the contextual init function to be called before declaration
just like the standard init function.
This is needed when moving the File Output node to use socket
declaration.
Pull Request: https://projects.blender.org/blender/blender/pulls/141203
Saved files in 4.5 with a compositing node tree containing a Normal
Node with animated 'Dot' input crash in 5.0.
A test case with animated dot and normal inputs was added as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/140908
This patch removes the Vector Curves node that was deprecated in 4.5 and
was planned for removal in 5.0. The common Shading Vector Curves node
should be used instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/140529
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 patch removes node init functions that currently exist only for
forward compatibility and moves the logic to the forward compatibility
section of node writing. This is to avoid allocating unused data
throughout the 5.x series.
Pull Request: https://projects.blender.org/blender/blender/pulls/140273
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
Implementation of #127106.
This is just a visual representation of the field/single/grid
status of sockets to make the workflow more intuitive. With
a visual representation for volume grid sockets, volume features
should be unblocked for further development. The structure type
will also be used to distinguish list sockets in the interface.
Group input nodes now have a "Structure Type" option instead of
the existing "Single Value Only". Usually the auto option should be
enough, but in some cases where the inferencing cannot (yet) make
a clear determination, it can be helpful to choose a specific type.
The new visualization and the group input structure type option
are hidden behind a new experimental option for now.
Pull Request: https://projects.blender.org/blender/blender/pulls/134811
This is similar to how Value/Vector/Integer/... nodes are automatically
initialized when they are created using link-drag-search.
Strings require some special case handling here but that seems fine. The
`node_socket_move_default_value` function is already fairly specific for the
different value nodes.
Pull Request: https://projects.blender.org/blender/blender/pulls/139478
This patch turns the Blur node options to inputs.
Size is now a 2D vector and replaces the Size X and Y option. Bokeh was
renamed to Separable to reflect its actual function. Relative was
removed in favor of the newly added Relative To Pixel node workflow.
There is a slight difference in variable size blurring due to float vs
integer computations, so two tests were updated.
Reference #137223.
Pull Request: https://projects.blender.org/blender/blender/pulls/139329
This patch adds support for 2D and 4D vector sockets. The default value
structure for vectors was extended to include a new dimensions input,
which can be 2, 3, or 4. The default value was also extended to be a
float4, but only some of its components might be used depending on the
dimensions members.
Each vector subtype now has three variants ending with 2D or 4D as a
prefix depending on its dimensions, and the 2D/4D prefix was taken into
account for the socket type RNA enum functions.
All node systems currently always treat the vectors as 3D, but support
for it in the compositor will shortly follow in another patch.
Depends on #138805.
Pull Request: https://projects.blender.org/blender/blender/pulls/138824
This patch turns the options of the Color Balance node into inputs.
In the process, each of the wheels were split into two inputs, a base
float and a color. For instance, Gain is controlled using both a Base
Gain and Color Gain, the former controls the gain for all channels while
the latter controls it per channel.
Reference #137223.
Pull Request: https://projects.blender.org/blender/blender/pulls/138610
Use a similar convention for struct member identifiers,
(the identifiers without surrounding spaces). This allows the values
to be scanned and validated.
