Previously, whenever the zone detection algorithm could not find a result, zones
were just not drawn at all. This can be very confusing because it's not
necessarily obvious that something is wrong in this case.
Now, invalid zones and links that made them invalid have an error.
Note, we can't generally detect the "valid part" of zones when there are invalid
links, because it's ambiguous which links are valid. However, the solution here
is to remember the last valid zones, and to look at which links would invalidate
those. Since the zone-detection results in runtime-only data currently, the
error won't show when reopening the file for now.
Implementation wise, this works by keeping a potentially outdated version of the
last valid zones around, even when the zone detection failed. For that to work,
I had to change some node pointers to node identifiers in the zone structs, so
that it is safe to access them even if the nodes have been removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/139044
Previously, internal links of node are only shown when the link is muted AND
when the corresponding output is linked to something else. I can't think of any
reason for why it's important whether the output is linked or not. It seems
showing the internal link is always useful.
This patch makes it so that all internal links are always shown when a node is
muted, regardless of whether the corresponding output socket is linked or not.
Pull Request: https://projects.blender.org/blender/blender/pulls/139086
Previously, it was not possible to switch a menu based on another menu. This
patch adds support for this.
Usually, menu sockets are drawn without the label in nodes currently. Now there
is one exception: the Menu Switch node when it switches another menu. If the
label is not shown, the UI is missing crucial information.
Pull Request: https://projects.blender.org/blender/blender/pulls/138704
Previously, nodes which had their own special internal-links-behavior were
hardcoded in node tree update code. Now that is decentralized so that more nodes
can use this functionality without leaking special cases into general code.
Pull Request: https://projects.blender.org/blender/blender/pulls/138712
Previously, we had shown link errors on the target node as part of the node
warning system. While better than not showing any information about invalid
links (as was the state before that), it's still not ideal because it's easy to
miss when just looking at the link.
This patch adds an error icon in the middle of the invalid link. When hovering
over it, it shows the error text. When the middle of the link is not in view but
part of the link is, then the error icon will also stay visible.
Pull Request: https://projects.blender.org/blender/blender/pulls/138529
Previously, internal links used the same heuristics as most other nodes. However,
this is more problematic here, because I intend to use the same internal links
for the case when no closure is connected. The behavior in this case should not
change in the future if we decide to change the heuristic for internal links for
muted nodes.
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/136134
Adds the option to create a boolean socket that can be used as a panel toggle.
This allows creating simpler and more compact node group UIs when a panel
can be "disabled".
The toggle input is a normal input socket that is just drawn a bit differently in
the UI. Whether a boolean is a toggle input or not does not affect evaluation.
Also see #133936 for guides on how to add and remove panel toggles.
Pull Request: https://projects.blender.org/blender/blender/pulls/133936
The enum items propagation mechanism for Menu sockets makes a local copy of item
pointers to propagate between node group inputs and interface definitions.
In case these items are not used (e.g. because they are already shared with the
socket) the local copy must still be released to avoid leaking the memory.
This only happens with more than 4 enum items, because of the internal default
buffer for `Vector`.
Pull Request: https://projects.blender.org/blender/blender/pulls/135226
Restriction of the nodes api to clearly define never-null function arguments.
Side effects: some assertions and null-check (with early return) were removed.
On the caller side is ensured to never derefer null to pass argument (mainly in RNA).
In addition, one pointer argument now actually a return type.
By-reference return types instead of pointers going to be separate kind of
change since also imply of cleaning up variables created from reference.
Also good future improvement would be to mark a copy-constructor as
explicit for DNA node types.
Pull Request: https://projects.blender.org/blender/blender/pulls/134627
Currently, tree, node and socket types are always freed immediately when the
Python code unregisters them. This is problematic, because there may still be
references to those type pointers in evaluated data owned by potentially various
depsgraphs. It's not possible to change data in these depsgraphs, because they
may be independent from the original data and might be worked on by a separate
thread. So when the type pointers are freed directly, there will be a lot of
dangling pointers in evaluated copies. Since those are used to free the nodes,
there will be a crash when the depsgraph updates. In practice, this does not
happen that often, because typically custom node tree addons are not disabled
while in use. They still used to crash often, but only when Blender exits and
unregisters all types.
The solution is to just keep the typeinfo pointers alive and free them all at
the very end. This obviously has the downside that the list of pointers we need
to keep track of can grow endlessly, however in practice that doesn't really
happen under any normal circumstances.
I'm still getting some other crashes when enabling/disabling Sverchok while
testing, but not entirely reliably and also without this patch (the crash there
happens in RNA code). So some additional work will probably be needed later to
make this work properly in all cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/134360
Currently UI code always has to use char pointers when interacting with
the translation system. This makes benefiting from the use C++ strings
and StringRef more difficult. That means we're leaving some type safety
and performance on the table. This PR adds StringRef overloads to the
translation API functions and removes the few calls to `.c_str()` that
are now unnecessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/133887
Changes to the compositor Normal node does not propagate and the
compositor result is not updated. That's because the node is a special
case since its output socket value is used as its input property, which
is not tracked by the node update code.
Apparently, a similar node exists in shader nodes, and a workaround is
implemented for that node in the node updater, so we just need to extend
that check to include the compositor node as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/133803
This patch automatically grays out input values which can't affect the output
currently. It works with inputs of group nodes, geometry nodes modifiers and
node tools.
To achieve this, it analyses the node tree and partially evaluates it to figure
out which group inputs are currently not linked to an output or are disabled by e.g.
some switch node.
Original proposal: https://devtalk.blender.org/t/dynamic-socket-visibility/31874
Related info in blog post:
https://code.blender.org/2023/11/geometry-nodes-workshop-november-2023/#dynamic-socket-visibility
Follow up task for designing a UI that allows hiding sockets: #132706
Limitations:
* The inferencing does not update correctly when a socket starts being
animated/driven. I haven't found a good way to invalidate the cache in a good
way reliably yet. It's only a very short term problem though. It fixes itself
after the next modification of the node tree and is only noticeable when
animating some specific sockets such as the switch node condition.
* Whether a socket is grayed out is not exposed in the Python API yet. That will
be done separately.
* Only a partial evaluation is done to determine if an input affects an output.
There should be no cases where a socket is found to be unused when it can actually
affect the output. However, there can be cases where a socket is inferenced to be used
even if it is not due to some complex condition. Depending on the exact circumstances,
this can either be improved or the condition in the node tree should be simplified.
Pull Request: https://projects.blender.org/blender/blender/pulls/132219
Using the `BKE_id_owner_get` during the node tree update can avoid having to
iterate over lots of data-blocks in common cases. Previously, the code had to
iterate over all potential owners of node group to find the correct one.
Pull Request: https://projects.blender.org/blender/blender/pulls/132903
Main goals of this refactor:
* Make it more obvious which update function should be used.
* Make it more obvious which parameters are required by using references instead
of pointers.
* Support passing in multiple modified trees instead of just a single one.
No functional changes are expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/132862
The `bNode.type_legacy` is still used in many places to check if a node is a
specific type. However, going forward it's better to rely more on the idname
than on this legacy integer type. Some more information is available in #132858.
The added utility method can be used like so:
`node->is_type("GeometryNodeMenuSwitch")`. Previously one would have written
`node->type_legacy == GEO_NODE_MENU_SWITCH`. The `is_type` method internally
checks that the passed in string is a valid node identifier to make it more
likely that we catch typos early.
Pull Request: https://projects.blender.org/blender/blender/pulls/132863
The new description for `bNode.type_legacy`:
```
/**
* Legacy integer type for nodes. It does not uniquely identify a node type, only the `idname`
* does that. For example, all custom nodes use #NODE_CUSTOM but do have different idnames.
* This is mainly kept for compatibility reasons.
*
* Currently, this type is also used in many parts of Blender, but that should slowly be phased
* out by either relying on idnames, accessor methods like `node.is_reroute()`.
*
* A main benefit of this integer type over using idnames currently is that integer comparison is
* much cheaper than string comparison, especially if many idnames have the same prefix (e.g.
* "GeometryNode"). Eventually, we could introduce cheap-to-compare runtime identifier for node
* types. That could mean e.g. using `ustring` for idnames (where string comparison is just
* pointer comparison), or using a run-time generated integer that is automatically assigned when
* node types are registered.
*/
```
Pull Request: https://projects.blender.org/blender/blender/pulls/132858
Make the type structs non-trivial, use new and delete for allocation and
freeing, and use std::string for most strings they contain. Also use
StringRef instead of char pointers in a few places. Mainly this improves
ergonomics when working with the strings.
Pull Request: https://projects.blender.org/blender/blender/pulls/132750
Instead of storing an optional in the runtime data of each node,
move the field status for the socket to an array in the node tree's
runtime data. This wasn't possible before because selecting nodes
reordered nodes which caused too much cache recomputation.
The benefit is having less geometry-nodes specific data in the
node socket runtime struct, and a slight move to a more data-
oriented storage format.
Pull Request: https://projects.blender.org/blender/blender/pulls/131822
This avoids assuming that `BKE_ntree_update_main` has run on a node tree before
the depsgraph is build. The update code already finds the dependencies to
determine if a relations update is necessary or not. To avoid detecting these
dependencies again (which requires iterating over all the nested nodes), they
were cached on the node group so that they can be used when the depsgraph is
build.
However, since the update code does not run in all necessary cases yet
(#131598), this does not work currently. This patch fixes the situation by
removing the optimization of not having to find all dependencies again when the
depsgraph is build.
This optimization can be introduced again after we can be more sure that the
node tree update code runs whenever the node tree changes (which is what #131665
tries, but requires more discussion).
Pull Request: https://projects.blender.org/blender/blender/pulls/131685
Previously, the data-block dependencies were always detected in
`update_depsgraph` in `MOD_nodes.cc`. This would only be called when something
called `DEG_relations_tag_update` before. We don't want to trigger a depsgraph
rebuild after each operation in the node editor, as that would be expensive.
However, that also meant that we often had to add data-block dependencies that
are not actually used, but might be used if the user changed e.g. a link. A
typical example for that is a object socket that has a default value, but the
socket is also linked.
Now, the dependencies referenced by the node tree are collected by the node tree
update code which runs after all changes. This way we can detect whether the
dependencies have changed. Only if they have changed, a depsgraph rebuild is
triggered. This now allows also taking into account the mute status of nodes and
whether an input is linked.
There are still more things that could be taken into account. Most obviously
whether a node is connected to an output. This can be done later. The most
tricky aspect here is probably that we also have to consider all viewer nodes as
output, because at the time the node runs, it's not known which viewer will
actually be used (which depends on other editors).
This also cleans up some special cases we had for e.g. the scene time node where
we always had to trigger a depsgraph rebuild when it was added/removed because
of its time dependence. This is now part of a more general system.
This fixes#109219.
Pull Request: https://projects.blender.org/blender/blender/pulls/131446
NOTE: This also required some changes to Cycles code itself, who is now
directly including `BKE_image.hh` instead of declaring a few prototypes
of these functions in its `blender/utils.h` header (due to C++ functions
names mangling, this was not working anymore).
Pull Request: https://projects.blender.org/blender/blender/pulls/130174
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
Adds support for the "Menu" socket type in for-each-element zones. This
only includes field inputs and their matching per-element values, but
not outputting attributes of type Menu (Menu attributes are not
generally supported at this point).
A dedicated enum propagation function is added for the zone input node.
This isn't technically necessary: the first 2 inputs and outputs should
be ignored but are not menus anyway. However, this is clearer and
provides a place for future changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/128106
This adds a new type of zone to Geometry Nodes that allows executing some nodes
for each element in a geometry.
## Features
* The `Selection` input allows iterating over a subset of elements on the set
domain.
* Fields passed into the input node are available as single values inside of the
zone.
* The input geometry can be split up into separate (completely independent)
geometries for each element (on all domains except face corner).
* New attributes can be created on the input geometry by outputting a single
value from each iteration.
* New geometries can be generated in each iteration.
* All of these geometries are joined to form the final output.
* Attributes from the input geometry are propagated to the output
geometries.
## Evaluation
The evaluation strategy is similar to the one used for repeat zones. Namely, it
dynamically builds a `lazy_function::Graph` once it knows how many iterations
are necessary. It contains a separate node for each iteration. The inputs for
each iteration are hardcoded into the graph. The outputs of each iteration a
passed to a separate lazy-function that reduces all the values down to the final
outputs. This final output can have a huge number of inputs and that is not
ideal for multi-threading yet, but that can still be improved in the future.
## Performance
There is a non-neglilible amount of overhead for each iteration. The overhead is
way larger than the per-element overhead when just doing field evaluation.
Therefore, normal field evaluation should be preferred when possible. That can
partially still be optimized if there is only some number crunching going on in
the zone but that optimization is not implemented yet.
However, processing many small geometries (e.g. each hair of a character
separately) will likely **always be slower** than working on fewer larger
geoemtries. The additional flexibility you get by processing each element
separately comes at the cost that Blender can't optimize the operation as well.
For node groups that need to handle lots of geometry elements, we recommend
trying to design the node setup so that iteration over tiny sub-geometries is
not required.
An opposite point is true as well though. It can be faster to process more
medium sized geometries in parallel than fewer very large geometries because of
more multi-threading opportunities. The exact threshold between tiny, medium and
large geometries depends on a lot of factors though.
Overall, this initial version of the new zone does not implement all
optimization opportunities yet, but the points mentioned above will still hold
true later.
Pull Request: https://projects.blender.org/blender/blender/pulls/127331
This implements the `Warning` node that allows node groups to communicate
expectations about input values to the user.
By default, the `Warning` node is only evaluated if the node group that contains
it is evaluated in any way. This is better than always evaluating it, because
that could trigger lots of unnecessary evaluation in parts of the potentially
large node tree which should be ignored. In this basic mode, the output of the
node should not be connected to anything and it must not be in a zone.
For more fine-grained control for when the `Warning` node should be evaluated,
one can use the boolean output which is just a pass-through of the `Show` input.
If this output is used, the `Warning` node will only be evaluated if its output
is used. A simple way to use it is to control a Switch node with it that e.g.
"disables" a specific output when the inputs are invalid. In this case, the
`Warning` node may also be in a zone.
The node allows the user to choose between 3 severity levels: Error, Warning and
Info. Those are the same levels that we use internally. Currently, the error and
warning mode are pretty much the same, but that may change in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/125544
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
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 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
Extract
- Add to Quick Favorites tooltip.
- "Mask", the name of a newly created mask (DATA_).
- "New" in the context of the new mask ID button.
- A few strings using BLI_STR_UTF8_ defines were not extracted.
Take the special characters out of the translation macros.
- "External" menu items from the filebrowser's Files context
menu (right-click on a file). These items were already extracted,
but not translated.
Improve
- Separate formatted error message "%s is not compatible with
["the specified", "any"] 'refresh' options" into two messages.
Disambiguate
- Use Action context for new F-modifiers' names. This is already used
for the "type" operator prop.
- Translate ImportHelper's default confirmation text using the
Operator context, as it uses the operator name which is extracted
with this context.
- "Scale" can be a noun, the scale of something, or a verb, to scale
something. The latter mostly uses the Operator context, so apply
this context to verbs, and the default contexts to nouns.
- "Scale Influence" can mean "Influence on Scale" (tracking
stabilization) and "to Scale the Influence" (dynamic paint canvas).
- "Object Line Art" as type of Line Art to add, as opposed to the
active object's Line Art settings.
- Float to Integer node: use NodeTree context for the node label, as
this is already extracted and used for the enum.
Do not translate
- Sequencer labels containing only a string formatting field.
Some issues reported by Gabriel Gazzán and Ye Gui.
Pull Request: https://projects.blender.org/blender/blender/pulls/122283
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
