Volumes and grids were not yet handled by the Geometry Nodes value
logging system. This patch adds basic information (number of grids)
to the value logger and node tooltips.
Pull Request: https://projects.blender.org/blender/blender/pulls/121622
This is slight optimization. Number of nodes with additional outputs like `Valid`
flag of other math-related things will be more in future, its better to strict api
and do not evaluate even singles. This also can reduce number of logged values.
Pull Request: https://projects.blender.org/blender/blender/pulls/121799
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
This allows setting a color tag for node groups which affects the header
color of group nodes. With this, node groups can look even more similar
to built-in nodes. The only remaining difference is the node group icon in
the node header.
Blender has quite a few different built-in color tags. Most of those are
exposed with very few exceptions. For example, the layout, interface
and pattern categories are not exposed because they are only for built-in
nodes or are not used anymore.
It's generally agreed upon that the set of different color tags is likely too
large. Some differences between color make more sense in some contexts
than in others. In the interest of consistency, it was decided to expose all
these categories anyway. If we ever decide to consolidate them, the worst
that can happen is that a group looses it's category, which wouldn't be too bad.
Pull Request: https://projects.blender.org/blender/blender/pulls/121385
This allows node groups to have a description that is shown in the add menu
or when hovering over the node header.
This new description is stored in `bNodeTree.description`. Unfortunately, it
conflicts a bit with `ID.asset_data.description`. The difference is that the latter
only exists for assets. However, it makes sense for node groups to have
descriptions even if they are not assets (just like `static` functions in C++ should
also be able to have comments). In some cases, node groups are also generated
by addons for a specific purpose. Those should still have a description without
being reusable to make it easier to understand for users.
The solution here is to use the asset description if the node group is an asset,
and to use `bNodeTree.description` otherwise. The description is synced
automatically when marking or clearing assets.
A side benefit of this solution is that appended node group assets can keep their
description, which is currently always lost.
Pull Request: https://projects.blender.org/blender/blender/pulls/121334
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
