The main goal is to simplify adding support for nested node panels. The patch
makes use of the updated recursive node declarations introduced in
6ffc585fb8.
The main changes are:
* Rewritten node drawing in a way that makes ui design decisions like panel
visibility and margins more explicit. Especially the handling of margins is
much better now imo. Previously, it was very hard to change the margin for
specific cases without accidentally breaking other situations. Now each
possible case has an explicit margin. This needs a few more lines of code but
is much easier to work with.
* Rewritten node drawing in panel (sidebar + material properties) using the new
ways to iterate over the declaration.
* It's possible to add custom layouts at any point in the node declaration now.
This also replaces the need for having a `draw_buttons` callback for panels.
Pull Request: https://projects.blender.org/blender/blender/pulls/128822
This refactors the lifetime analysis of anonymous attributes in geometry nodes.
The refactor has a couple of goals:
* Use a better and simpler abstraction that can be used when building the
lazy-function graph. We currently have a bunch of duplicate code to handle
"field source" and "caller propagation" attributes. This is now unified so
that one only has to worry about one kind of "reference sets".
* Make the abstraction compatible with handling bundles and closures in case we
want to support them in the future. Both types can contain geometries and
fields so they need to be taken into account when determining lifetimes.
* Make more parts independent of the concept of "anonymous attributes". In
theory, there could be more kinds of referenced data whose lifetimes need to
be managed. I don't have any concrete plans for adding any though.
At its core, deterministic anonymous attributes still work the same they have
been since they became deterministic [0]. Even the generated lazy-function graph
is still pretty much or even exactly the same as before.
The patch renames `AnonymousAttributeSet` to the more general
`GeometryNodesReferenceSet` which is more. This also makes more places
independent of the concept of anonymous attributes. Functionally, this still the
same though. It's only used in the internals of geometry nodes nowadays. Most
code just gets an `AttributeFilter` that is based on it.
[0]: https://archive.blender.org/developer/D16858
Pull Request: https://projects.blender.org/blender/blender/pulls/128667
The tricky thing here is that this graph is only generated while geometry nodes
is evaluated and is generally only stored temporarily. To make it accessible via
Python, the accessor method will cause a reevaluation specifically to log the
generated graph.
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 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
Blender shows invalid links in red in the node editor. However, it's not always
obvious why some links don't work, especially for beginners. This patch adds
additional information for every invalid link on the node that it links to.
The following error messages are added:
* Invalid link because of missing implicit conversions.
* Link cycle in node tree.
* A link from a field to a socket that does not support fields.
* Using the same menu on multiple Menu Switch nodes.
Currently, there are some per tree-type special cases in the link validation code.
In the future, this should be moved to tree type specific callbacks.
Pull Request: https://projects.blender.org/blender/blender/pulls/121976
Move all header file into namespace.
Unnecessary namespaces was removed from implementations file.
Part of forward declarations in header was moved in the top part
of file just to do not have a lot of separate namespaces.
Pull Request: https://projects.blender.org/blender/blender/pulls/121637
To know if link is connected to dangling reroute and can be skipped
as value-less, we need to know if reroute is dangling. This requires
graph traversal. Currently this is done by non-recursive iteration.
But this can lead quadratic complexity for some of the cases.
Other way is to make this linear while cache building.
Pull Request: https://projects.blender.org/blender/blender/pulls/120375
Currently we have some old code from shader/compositor/texture nodes
that stores runtime data during and after evaluation on the node tree
itself. This is meant to be avoided, since the node tree is just meant
to be evaluation _instructions_.
Pull Request: https://projects.blender.org/blender/blender/pulls/118056
It shouldn't be possible to retrieve a mutable interface item from
a const node tree. Unfortunately that means we have to duplicate
the accessor methods. Fortunately they are very small.
The goal of this patch is to allow us to use dynamic node declarations
for various nodes in a future version without breaking forward compatibility.
The same kind of change should be added to Blender 3.6.
The code added here is not supposed to end up in `main`, so it has to be
removed when merging the release branch.
Pull Request: https://projects.blender.org/blender/blender/pulls/113497
In #112326 the socket visibility functions were updated to take the
open/closed state of panels into account for visibility of the socket
icon. However, in "hidden" (collapsed) nodes the panels should be
ignored entirely, drawing all sockets on the root level. This requires
looking at the node flags to determine socket icon visibility, so a
simple method of `bNodeSocket` is not sufficient.
This patch moves the more complex visibility queries for sockets into
`bNode`, where both node and socket flags can be accessed. These should
be used for actual visibility rather than the plain flag accessors on
`bNodeSocket`.
Renamed `is_visible_or_panel_closed` back to just `is_visible`, the
other `is_visible` variant is now integrated in `bNode::is_socket_drawn`.
Pull Request: https://projects.blender.org/blender/blender/pulls/112520
#112019 included open/closed state of the parent panel in socket
visibility calculation. This prevents dragging links, but also disables
other features that should still work, such as drawing links.
A narrower condition is needed for icon visibility vs. general socket
visibility. The cases which use the new `is_icon_visible` condition:
- Drawing socket selection outlines (same as unselected sockets)
- Drawing multi-input sockets (same as unselected sockets)
- `node_find_indicated_socket`, used by a wide range of mouse click
operators, including the link-drag operator that was cause for
#112019.
Cases using the original `is_visible` (true even if parent panel is
collapsed):
- `nodeLinkIsHidden` draws links only when at least one socket is
visible.
- `node_update_basis`, sockets still added to layout even if icon isn't
rendered.
- `node_update_hidden`, panels are ignored for "hidden" nodes, all
sockets are rendered.
- `NODE_OT_link_make` operator for finding "best" sockets to connect.
- `node_link_viewer` finding sockets to connect to a viewer node.
- `get_main_socket` used for insert-on-links (find sockets to splice
into) and some shader previews
- `node_gather_link_searches`, suggestions for adding a new node at the
end of a link.
Pull Request: https://projects.blender.org/blender/blender/pulls/112326
Calling an API function after the node panels patch does not internally
tag the node tree with `NTREE_CHANGED_INTERFACE` any more, because the
node tree is not directly accessible from `bNodeTreeInterface`. Before
node panels the API functions for interfaces could tag the tree directly
for later update consideration, which now requires explicit tagging
calls.
The fix is to add a flag and mutex directly to `bNodeTreeInterface`, so
API methods can tag after updates. This mostly copies runtime data
concepts from `bNodeTree`. The `ensure_interface_cache` method is
equivalent to `ensure_topology_cache` and should be called before
accessing `interface_inputs` and similar cache data.
Pull Request: https://projects.blender.org/blender/blender/pulls/111741
Part 3/3 of #109135, #110272
Switch to new node group interfaces and deprecate old DNA and API.
This completes support for panels in node drawing and in node group
interface declarations in particular.
The new node group interface DNA and RNA code has been added in parts
1 and 2 (#110885, #110952) but has not be enabled yet. This commit
completes the integration by
* enabling the new RNA API
* using the new API in UI
* read/write new interfaces from blend files
* add versioning for backward compatibility
* add forward-compatible writing code to reconstruct old interfaces
All places accessing node group interface declarations should now be
using the new API. A runtime cache has been added that allows simple
linear access to socket inputs and outputs even when a panel hierarchy
is used.
Old DNA has been deprecated and should only be accessed for versioning
(inputs/outputs renamed to inputs_legacy/outputs_legacy to catch
errors). Versioning code ensures both backward and forward
compatibility of existing files.
The API for old interfaces is removed. The new API is very similar but
is defined on the `ntree.interface` instead of the `ntree` directly.
Breaking change notifications and detailed instructions for migrating
will be added.
A python test has been added for the node group API functions. This
includes new functionality such as creating panels and moving items
between different levels.
This patch does not yet contain panel representations in the modifier
UI. This has been tested in a separate branch and will be added with a
later PR (#108565).
Pull Request: https://projects.blender.org/blender/blender/pulls/111348
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
First implementation of node previews in the shader node editor. Using
the same user interface as compositor node previews, most shader nodes
can now be previewed (except group in/output and material output).
This is currently still an experimental feature, as polishing of the
user experience and performance improvements are planned. These will
be easier to do as incremental changes on this implementation.
See #110353 for details on the work that remains to be done and known
limitations.
Implementation notes:
We take advantage of the `RenderResult` available as `ImBuf` images to
store a `Render` for every viewed nested node tree present in a
`SpaceNode`. The computation is initiated at the moment of drawing nodes
overlays.
One render is started for the current nodetree, having a `ViewLayer`
associated with each previewed node. We separate the previewed nodes in
two categories: the shader ones and the non-shader ones.
- For non-shader nodes, we use AOVs which highly speed up the rendering
process by rendering every non-shader nodes at the same time. They are
rendered in the first `ViewLayer`.
- For shader nodes, we render them each in a different `ViewLayer`, by
rerouting the node to the output of the material in the preview scene.
The preview scene takes the same aspect as the Material preview scene,
and the same preview object is used.
At the moment of drawing the node overlay, we take the `Render` of the
viewed node tree and extract the `ImBuf` of the wanted viewlayer/pass
for each previewed node.
Pull Request: https://projects.blender.org/blender/blender/pulls/110065
This feature is going to be replaced with a more thorough refactoring
of the node group interface UI, which has actual node drawing support
and a new API for integration of panels into nodes.
Design task: #109135
Implementation: #110272
Pull Request: https://projects.blender.org/blender/blender/pulls/110803
Move the node previews to the overlay region, atop each node.
It allows nodes to keep the same size when the preview is toggled,
which is more convenient for large nodes and large nodetrees.
The preview has to be drawn from `node_draw_extra_info_panel`
because there could be overlapping between info text and the preview.
When the node is out of the view, it also has to make sure that the
preview is also out of the view before exiting the draw function.
Pull Request: https://projects.blender.org/blender/blender/pulls/108001
The simulation state used by simulation nodes is owned by the modifier. Since a
geometry nodes setup can contain an arbitrary number of simulations, the modifier
has a mapping from `SimulationZoneID` to `SimulationZoneState`. This patch changes
what is used as `SimulationZoneID`.
Previously, the `SimulationZoneID` contained a list of `bNode::identifier` that described
the path from the root node tree to the simulation output node. This works ok in many
cases, but also has a significant problem: The `SimulationZoneID` changes when moving
the simulation zone into or out of a node group. This implies that any of these operations
loses the mapping from zone to simulation state, invalidating the cache or even baked data.
The goal of this patch is to introduce a single-integer ID that identifies a (nested) simulation
zone and is stable even when grouping and un-grouping. The ID should be stable even if the
node group containing the (nested) simulation zone is in a separate linked .blend file and
that linked file is changed.
In the future, the same kind of ID can be used to store e.g. checkpoint/baked/frozen data
in the modifier.
To achieve the described goal, node trees can now store an arbitrary number of nested node
references (an array of `bNestedNodeRef`). Each nested node reference has an ID that is
unique within the current node tree. The node tree does not store the entire path to the
nested node. Instead it only know which group node the nested node is in, and what the
nested node ID of the node is within that group. Grouping and un-grouping operations
have to update the nested node references to keep the IDs stable. Importantly though,
these operations only have to care about the two node groups that are affected. IDs in
higher level node groups remain unchanged by design.
A consequence of this design is that every `bNodeTree` now has a `bNestedNodeRef`
for every (nested) simulation zone. Two instances of the same simulation zone (because
a node group is reused) are referenced by two separate `bNestedNodeRef`. This is
important to keep in mind, because it also means that this solution doesn't scale well if
we wanted to use it to keep stable references to *all* nested nodes. I can't think of a
solution that fulfills the described requirements but scales better with more nodes. For
that reason, this solution should only be used when we want to store data for each
referenced nested node at the top level (like we do for simulations).
This is not a replacement for `ViewerPath` which can store a path to data in a node tree
without changing the node tree. Also `ViewerPath` can contain information like the loop
iteration that should be viewed (#109164). `bNestedNodeRef` can't differentiate between
different iterations of a loop. This also means that simulations can't be used inside of a
loop (loops inside of a simulation work fine though).
When baking, the new stable ID is now written to disk, which means that baked data is
not invalidated by grouping/un-grouping operations. Backward compatibility for baked
data is provided, but only works as long as the simulation zone has not been moved to
a different node group yet. Forward compatibility for the baked data is not provided
(so older versions can't load the data baked with a newer version of Blender).
Pull Request: https://projects.blender.org/blender/blender/pulls/109444
Adds an optional list of panels to node trees. Each socket can be
assigned a panel. UI panels will be created in the future in the
modifier for these grouped sockets.
Panels are stored as a pointer array in node trees, next to socket
declarations. Each panel has a name, but it does not have to be unique.
In future a panel might also store whether it is visible by default and
similar information.
C API and RNA API are both added. Panels and their socket
assignments are accessible to users through another list in the "Group"
tab of the node editor sidebar.
Sockets in the same panel will remain together even when adding,
removing, or moving sockets or panels, renaming, etc.
A socket can be moved up or down within a panel but each panel
remains a contiguous block. Actual tree views may be created later.
Pull Request: https://projects.blender.org/blender/blender/pulls/108649
Previously, there were two independent algorithms for analysing how anonymous
attributes are used in a node tree: One that just computed the `aal::RelationsInNode`
for an entire node tree and one that performed a more in depth analysis to
determine how far anonymous attributes should be propagated.
As it turns out, both operations can also be done at the same time and the result
can be cached on the node tree. This reduces the amount of code and allows for
better code reuse.
This simplification is likely only an intermediate step as things will probably have
to be refactored further to support e.g. serial loops (#108896).
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
See: https://projects.blender.org/blender/blender/issues/103343
Changes:
1. Added `BKE_node.hh` file. New file includes old one.
2. Functions moved to new file. Redundant `(void)`, `struct` are removed.
3. All cpp includes replaced from `.h` on `.hh`.
4. Everything in `BKE_node.hh` is on `blender::bke` namespace.
5. All implementation functions moved in namespace.
6. Function names (`BKE_node_*`) changed to `blender::bke::node_*`.
7. `eNodeSizePreset` now is a class, with renamed items.
Pull Request: https://projects.blender.org/blender/blender/pulls/107790
This adds support for building simulations with geometry nodes. A new
`Simulation Input` and `Simulation Output` node allow maintaining a
simulation state across multiple frames. Together these two nodes form
a `simulation zone` which contains all the nodes that update the simulation
state from one frame to the next.
A new simulation zone can be added via the menu
(`Simulation > Simulation Zone`) or with the node add search.
The simulation state contains a geometry by default. However, it is possible
to add multiple geometry sockets as well as other socket types. Currently,
field inputs are evaluated and stored for the preceding geometry socket in
the order that the sockets are shown. Simulation state items can be added
by linking one of the empty sockets to something else. In the sidebar, there
is a new panel that allows adding, removing and reordering these sockets.
The simulation nodes behave as follows:
* On the first frame, the inputs of the `Simulation Input` node are evaluated
to initialize the simulation state. In later frames these sockets are not
evaluated anymore. The `Delta Time` at the first frame is zero, but the
simulation zone is still evaluated.
* On every next frame, the `Simulation Input` node outputs the simulation
state of the previous frame. Nodes in the simulation zone can edit that
data in arbitrary ways, also taking into account the `Delta Time`. The new
simulation state has to be passed to the `Simulation Output` node where it
is cached and forwarded.
* On a frame that is already cached or baked, the nodes in the simulation
zone are not evaluated, because the `Simulation Output` node can return
the previously cached data directly.
It is not allowed to connect sockets from inside the simulation zone to the
outside without going through the `Simulation Output` node. This is a necessary
restriction to make caching and sub-frame interpolation work. Links can go into
the simulation zone without problems though.
Anonymous attributes are not propagated by the simulation nodes unless they
are explicitly stored in the simulation state. This is unfortunate, but
currently there is no practical and reliable alternative. The core problem
is detecting which anonymous attributes will be required for the simulation
and afterwards. While we can detect this for the current evaluation, we can't
look into the future in time to see what data will be necessary. We intend to
make it easier to explicitly pass data through a simulation in the future,
even if the simulation is in a nested node group.
There is a new `Simulation Nodes` panel in the physics tab in the properties
editor. It allows baking all simulation zones on the selected objects. The
baking options are intentially kept at a minimum for this MVP. More features
for simulation baking as well as baking in general can be expected to be added
separately.
All baked data is stored on disk in a folder next to the .blend file. #106937
describes how baking is implemented in more detail. Volumes can not be baked
yet and materials are lost during baking for now. Packing the baked data into
the .blend file is not yet supported.
The timeline indicates which frames are currently cached, baked or cached but
invalidated by user-changes.
Simulation input and output nodes are internally linked together by their
`bNode.identifier` which stays the same even if the node name changes. They
are generally added and removed together. However, there are still cases where
"dangling" simulation nodes can be created currently. Those generally don't
cause harm, but would be nice to avoid this in more cases in the future.
Co-authored-by: Hans Goudey <h.goudey@me.com>
Co-authored-by: Lukas Tönne <lukas@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/104924
Previously the only way to control the subtype was to remove the group
input or output and create it again. This commit adds a dropdown to
change an existing socket, for supported socket types.
Based on a patch by Angus Stanton: https://developer.blender.org/D15715
It was necessary to fix the UI code slightly; the layout's context
wasn't being used in calls to an operator's enum items callback.
Pull Request: https://projects.blender.org/blender/blender/pulls/105614
The crash is fixed by reverting 87fd798ae3 and
some follow up commits. While it would generally be nice to move to a more
SoA format for these things, we are not there yet and this is causing more
trouble than it's worth currently. The main difficulty is that the socket
indices are changed by many different operations which invalidates the array
too often and led to many follow up bugs.
Pull Request: https://projects.blender.org/blender/blender/pulls/105877
Nodes are sorted based on the selection. In some cases (even depending
on processor speed, nodes can be selected and reordered, and another
operation can run before the next redraw). That gives a window where
operators mapped to the same input as selection can run with invalid
socket locations (which aren't updated after the nodes are reordered,
since they are stored in a separate array).
To fix this, move the socket locations from the node editor runtime
data to the node tree, tag them as invalid when the nodes are
reordered, and check for that status in a few more places.
A better longer term solution is not reordering nodes based on
UI status and instead storing the UI drawing order separately.
Pull Request #104420
Since internal links are only runtime data, we have the flexibility to
allocating every link individually. Instead we can store links directly
in the node runtime vector. This allows avoiding many small allocations
when copying and changing node trees.
In the future we could use a smaller type like a pair of sockets
instead of `bNodeLink` to save memory.
Differential Revision: https://developer.blender.org/D16960
Socket locations are set while drawing the node tree in the editor.
They can always be recalculated this way based on the node position and
other factors. Storing them in the socket is misleading. Plus, ideally
sockets would be quite small to store, this helps us move in that
direction.
Now the socket locations are stored as runtime data of the node editor,
making use of the new node topology cache's `index_in_tree` function
to make a SoA layout possible.
Differential Revision: https://developer.blender.org/D15874
Previously, the lifetimes of anonymous attributes were determined by
reference counts which were non-deterministic when multiple threads
are used. Now the lifetimes of anonymous attributes are handled
more explicitly and deterministically. This is a prerequisite for any kind
of caching, because caching the output of nodes that do things
non-deterministically and have "invisible inputs" (reference counts)
doesn't really work.
For more details for how deterministic lifetimes are achieved, see D16858.
No functional changes are expected. Small performance changes are expected
as well (within few percent, anything larger regressions should be reported as
bugs).
Differential Revision: https://developer.blender.org/D16858
