Previously, menu sockets were sometimes shown as integers or strings
in socket tooltips. Now, they are always shown as "Menu" type. This also
changes how these values are logged. Previously, they were logged as
strings. Now, only the integer identifier is logged and the name is looked
up when drawing the tooltip.
Pull Request: https://projects.blender.org/blender/blender/pulls/121236
Issue was in the fact that log should be propagated on source node and on parent node.
Instead of `group_node_id`, loggers need to have id of actual parent (zone node or node group) node.
This also fix issue with timings propagation on frame nodes.
Pull Request: https://projects.blender.org/blender/blender/pulls/120842
This changes the menu switch socket to use the socket-items system
(`NOD_socket_items.hh`) that is already used by the simulation zone, repeat
zone, bake node and index switch node. By using this system, the per-node
boilerplate can be removed significantly. This is especially important as we
plan to have dynamic socket amounts in more nodes in the future.
There are some user visible changes which make the node more consistent with
others:
* Move the menu items list into the properties panel as in 0c585a1b8a.
* Add an extend socket.
* Duplicating a menu item keeps the name of the old one.
There is also a (backward compatible) change in the Python API: It's now
possible to directly access `node.enum_items` and `node.active_index` instead of
having to use `node.enum_definition.enum_items`. This is consistent with the
other nodes. For backward compatibility, `node.enum_definition` still exists,
but simply returns the node itself.
Many API functions from `NodeEnumDefinition` like
`NodeEnumDefinition::remove_item` have been removed. Those are not used anymore
and are unnecessary boilerplate. If ever necessary, they can be implemented back
in terms of the socket-items system.
The socket-items system had to be extended a little bit to support the case for
the menu switch node where each socket item has a name but no type. Previously,
there was the case without name and type in the index switch node, and the case
with both in the bake node and zones. The system was trivial to extend to this
case.
Pull Request: https://projects.blender.org/blender/blender/pulls/121234
Currently support for data-block inputs is disabled because pointer
properties in operator properties aren't properly handled in Blender
(for more info, see 871c717c6e). This commit brings basic
support for them by storing strings (data-block names) in the operator
properties instead. The main downside of using strings compared other
theoretical solutions is that data-blocks from different library files
can have the same name. This solution won't work well for those cases.
However, it still brings a lot of utility to node tools for a relatively
simple code change.
I investigated two other solutions for this that didn't work out. Using
the recently added enum custom property support didn't work because
the data-block names would still have to be unique. Plus generating an
enum would require a bunch of boilerplate code. Extending the existing
button search code to handle integer session UID backed data-blocks was
much trickier than I expected. The code there is already quite spagetti-
like, and things got out of hand quickly. That's still valid future work
though. The implementation can be changed without breaking
compatibility of files.
Pull Request: https://projects.blender.org/blender/blender/pulls/121148
Currently for node tools we create and evaluate a temporary depsgraph
with all the selected object data-blocks and all data-blocks referenced
by the node tree.
Needless to say, this can be very slow when those data-blocks contain
arbitrary procedural operations. Re-evaluating all the selected objects
is particularly because it will give a slowdown even in very basic uses
of node tools.
Originally I hoped that geometry nodes could be made to work with
original as well as evaluated data-blocks. But that would require far
too many tricky changes and arguably isn't right design-wise anyway.
Instead of that, this commit makes node tools dependency graph
evaluation more fine-grained in a few ways.
1. Remove the evaluation of selected objects. These are always visible
in the viewport and part of the active depsgraph anyway. To protect
against cyclic dependencies, we now compare `orig_id` instead of the
object pointer itself.
2. Evaluate the node group and its dependencies in a separate depsgraph
used only when necessary. This allows using the original node tree
without any copies when it doesn't reference any data-blocks.
3. Evaluate IDs from node group inputs (from the redo panel) in the extra
depsgraph as well, only when necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/120723
`NOD_zone_socket_items.hh` contained code for different nodes. It's better to
split this into headers per node, because that scales better. Also it helps to
keep the code for each individual node more closely together.
Pull Request: https://projects.blender.org/blender/blender/pulls/120945
Improve working with multiple group input nodes by automatically
hiding new node group input sockets on any group input node with
hidden extension socket.
Whenever the extension socket is hidden, the user can now expect
the socket visibility of the group input node to stay fixed.
When the extension socket is shown on the other hand, the group input
node will update when sockets are added to the group interface.
Pull Request: https://projects.blender.org/blender/blender/pulls/120067
To ease the process of debugging a node group while creating
a node tool, while the group is visible in a node editor, log the socket
values from its last execution. The values are only logged for the
active object is nothing selected. The Viewer node is still not supported
because visualization would probably be very tricky.
Pull Request: https://projects.blender.org/blender/blender/pulls/120596
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
Avoid copying the positions array into the evaluated edit hints array
that's used to support editing with deformed positions when there is
a topology-changing procedural operation. In a simple test in sculpt
mode with 706k curve points, memory usage went from 78 to 70 MB.
This adds more duplication would be ideal, mainly because retrieving
the data with write access and making implicit sharing info for arbitrary
arrays aren't abstracted by implicit sharing utilities. It may be possible
to improve both of those aspects, either now or in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/120146
There are still a few places that are more complicated where the replacement
to `IDP_New` isn't obvious, but this commit replaces most uses of the ugly
`IDPropertyTemplate` usage.
Caused by 25a10c211f.
The socket_type field for socket declarations wasn't set for declarations
created from the node group interface DNA tree structure. Arguably the
socket types should be set by the constructors, but setting it in one more
place isn't bad either, and is a simple fix for now.
Previously, we haven't added this because there were plans to use these
declarations at a higher abstraction level where one declaration potentially
contains more than one socket. This hasn't happened yet, and we are also using
other ways to achieve dynamic socket amounts (using dynamic declarations).
Therefore, it is reasonable to simplify the code by storing the integer socket
type in the declaration directly.
Pull Request: https://projects.blender.org/blender/blender/pulls/119691
Support for having an input and output socket in the same socket declaration
builder was added for the original node panels to be able to support inline
sockets. However, those were generally disabled for now. As can be seen in the
simulation and repeat zone, inline sockets can work differently too. Having an
input and output in the same socket declaration builder builder makes some
things simpler but makes other things much harder. For example, the current
design wouldn't work all that well if the input and output socket has different
types. This is easier to do with the `align_with_previous_socket` approach.
I'm not yet entirely sure whether we want to use the same approach for
corresponding sockets in the node tree interface, but that can be tried and
decided separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/119599
The regression happened because object instances were turned into normal geometry
instances which don't have object-level visibility settings. Long term, this may not be
something we can support, but it's also not something we should break unnecessarily
and accidentally.
Pull Request: https://projects.blender.org/blender/blender/pulls/119370
For various reasons, the animation system can't properly update the node tree
so that the socket availability caused by changing node enum properties
propagates completely. So animating node properties that affect
socket visibility to change isn't possible without issues like crashes.
Unfortunately that wasn't disallowed before. In this commit there is
a balance of disabling animation on sockets that could reasonably expected
to affect socket visibility, and minimizing breaking changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/119221
When the "use_attribute" properties were added, boolean IDProperties
didn't exist. Then we didn't change it for a while because of forward
compatibility concerns. But currently we always convert boolean
properties to integer properties when saving anyway (since
2ea47e0def, so there is no issue with compatibility.
Using booleans makes working with the properties in the Python API
a bit friendlier.
Pull Request: https://projects.blender.org/blender/blender/pulls/119129
This adds a new special purpose container data structure that can be
used to gather many elements into many (potentially small) lists efficiently.
I originally worked on this data structure because I might want to use it
in #118772. However, also it's useful in the geometry nodes logger already.
I'm measuring a 10-20% speed improvement in my many-math-nodes file
when I enable logging for all sockets (not just the ones that are currently visible).
Pull Request: https://projects.blender.org/blender/blender/pulls/118774
Previously, the viewer node would work, but since the simulation output node
was never evaluated, the new simulation state was never stored. Now make
sure that the simulation output node is executed when there is an active viewer
inside the simulation.
Pull Request: https://projects.blender.org/blender/blender/pulls/118804
This changes the drawing of the zone nodes to align corresponding input
and output sockets. The resulting nodes are smaller and it's easier to see
how data is passed through them.
Drawing aligned sockets is already technically supported for quite a while
already, but we haven't used it so far. Using them for zone nodes seems to
provide benefits only. How we use aligned sockets in other nodes still has
to be discussed more.
This patch only changes run-time data. It doesn't affect what is written to
.blend files.
In the node declaration, aligned sockets are created by tagging a socket
so that it is aligned with the previous socket. This is a bit different from
what we had before where a single socket declaration would be used for
an input and output socket. I think the approach used here works better,
especially in a potential future scenario where the input and output socket
has a different type.
Pull Request: https://projects.blender.org/blender/blender/pulls/118335
Implements the design from #116067.
The socket type is called "Matrix" but it is often referred to as "Transform"
when that's what it is semantically. The attribute type is "4x4 Matrix" since
that's a lower level choice. Currently matrix sockets are always passed
around internally as `float4x4`, but that can be optimized in the future
when smaller types would give the same behavior.
A new "Matrix" utilities category has the following set of initial nodes"
- **Combine Transform**
- **Separate Transform**
- **Multiply Matrices**
- **Transform Direction**
- **Transform Vector**
- **Invert Matrix**
- **Transpose Matrix**
The nodes and socket type are behind an experimental flag for now,
which will give us time to make sure it's the right set of initial nodes.
The viewer node overlay doesn't support matrices-- they aren't supported
for rendering in general. They also aren't supported in the modifier interface
currently. But they are supported in the spreadsheet, where the value is
displayed in a tooltip.
Pull Request: https://projects.blender.org/blender/blender/pulls/116166
In 4.1 we deprecate the `Rotate Euler` node in favor of the `Rotate Rotation`
node which uses the new rotation socket type. The node is not removed
(for now) because that would come with compatibility issues. More generally,
we'll likely run into the situation where nodes are deprecated more often in the
future, without actually removing them to keep compatibility. This patch improves
how such nodes are handled in the UI.
The patch does three things:
* Adds a new `Utilities > Deprecated` entry in the add node menu in geometry nodes.
* Moves search items which are deprecated to the bottom in the search results
(currently, this only works in English, can be fixed in bcon3).
* Adds a new `bNodeType->deprecation_notice` that will result in a deprecation
warning when the node is used.
Pull Request: https://projects.blender.org/blender/blender/pulls/117905
With this patch, materials are kept intact in simulation zones and bake nodes
without any additional user action.
This implements the design proposed in #108410 to support referencing
data-blocks (only materials for now) in the baked data. The task also describes
why this is not a trivial issue. A previous attempt was implemented in #109703
but it didn't work well-enough.
The solution is to have an explicit `name (+ library name) -> data-block`
mapping that is stored in the modifier for each bake node and simulation zone.
The `library name` is necessary for it to be unique within a .blend file. Note
that this refers to the name of the `Library` data-block and not a file path.
The baked data only contains the names of the used data-blocks. When the baked
data is loaded, the correct material data-block is looked up from the mapping.
### Automatic Mapping Generation
The most tricky aspect of this approach is to make it feel mostly automatic.
From the user point-of-view, it should just work. Therefore, we don't want the
user to have to create the mapping manually in the majority of cases. Creating
the mapping automatically is difficult because the data-blocks that should
become part of the mapping are only known during depsgraph evaluation. So we
somehow have to gather the missing data blocks during evaluation and then write
the new mappings back to the original data.
While writing back to original data is something we do in some cases already,
the situation here is different, because we are actually creating new relations
between data-blocks. This also means that we'll have to do user-counting. Since
user counts in data-blocks are *not* atomic, we can't do that from multiple
threads at the same time. Also, under some circumstances, it may be necessary to
trigger depsgraph evaluation again after the write-back because it actually
affects the result.
To solve this, a small new API is added in `DEG_depsgraph_writeback_sync.hh`. It
allows gathering tasks which write back to original data in a synchronous way
which may also require a reevaluation.
### Accessing the Mapping
A new `BakeDataBlockMap` is passed to geometry nodes evaluation by the modifier.
This map allows getting the `ID` pointer that should be used for a specific
data-block name that is stored in baked data. It's also used to gather all the
missing data mappings during evaluation.
### Weak ID References
The baked/cached geometries may have references to other data-blocks (currently
only materials, but in the future also e.g. instanced objects/collections).
However, the pointers of these data-blocks are not stable over time. That is
especially true when storing/loading the data from disk, but also just when
playing back the animation. Therefore, the used data-blocks have to referenced
in a different way at run-time.
This is solved by adding `std::unique_ptr<bake::BakeMaterialsList>` to the
run-time data of various geometry data-blocks. If the data-block is cached over
a longer period of time (such that material pointers can't be used directly), it
stores the material name (+ library name) used by each material slot. When the
geometry is used again, the material pointers are restored using these weak name
references and the `BakeDataBlockMap`.
### Manual Mapping Management
There is a new `Data-Blocks` panel in the bake settings in the node editor
sidebar that allows inspecting and modifying the data-blocks that are used when
baking. The user can change what data-block a specific name is mapped to.
Pull Request: https://projects.blender.org/blender/blender/pulls/117043
Connecting an empty menu to the node group inputs causes a memory leak.
The `id_property_int_update_enum_items` function was always allocating
a new `enum_items` list, but then discarding it if there are no enum
items.
This patch adds support for _Menu Switch_ nodes and enum definitions in
node trees more generally. The design is based on the outcome of the
[2022 Nodes Workshop](https://code.blender.org/2022/11/geometry-nodes-workshop-2022/#menu-switch).
The _Menu Switch_ node is an advanced version of the _Switch_ node which
has a customizable **menu input socket** instead of a simple boolean.
The _items_ of this menu are owned by the node itself. Each item has a
name and description and unique identifier that is used internally. A
menu _socket_ represents a concrete value out of the list of items.
To enable selection of an enum value for unconnected sockets the menu is
presented as a dropdown list like built-in enums. When the socket is
connected a shared pointer to the enum definition is propagated along
links and stored in socket default values. This allows node groups to
expose a menu from an internal menu switch as a parameter. The enum
definition is a runtime copy of the enum items in DNA that allows
sharing.
A menu socket can have multiple connections, which can lead to
ambiguity. If two or more different menu source nodes are connected to a
socket it gets marked as _undefined_. Any connection to an undefined
menu socket is invalid as a hint to users that there is a problem. A
warning/error is also shown on nodes with undefined menu sockets.
At runtime the value of a menu socket is the simple integer identifier.
This can also be a field in geometry nodes. The identifier is unique
within each enum definition, and it is persistent even when items are
added, removed, or changed. Changing the name of an item does not affect
the internal identifier, so users can rename enum items without breaking
existing input values. This also persists if, for example, a linked node
group is temporarily unavailable.
Pull Request: https://projects.blender.org/blender/blender/pulls/113445
Possibly also fixes write past array boundaries.
Happens with the mikassa-shading.blend file, by simply opening
the file in debug mode. The fix is suggested by Jacques.
Pull Request: https://projects.blender.org/blender/blender/pulls/117331
The previous commit introduced a new `RPT_()` macro to translate
strings which are not tooltips or regular interface elements, but
longer reports or statuses.
This commit uses the new macro to translate many strings all over the
UI.
Most of it is a simple replace from `TIP_()` or `IFACE_()` to
`RPT_()`, but there are some additional changes:
- A few translations inside `BKE_report()` are removed altogether
because they are already handled by the translation system.
- Messages inside `UI_but_disable()` are no longer translated
manually, but they are handled by a new regex in the translation
system.
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
