Since a year and a half ago we've been switching to a new way to
represent what sockets a node should have called "declarations"
that's easier to use, clearer, and more flexible for upcoming
features like dynamic socket counts or generic type sockets.
All builtin nodes with a static set of sockets have switched, but one
missing area has been group nodes and group input/output nodes. These
nodes have **dynamic** declarations which change based on their
properties or the group they're inside of. This patch addresses that,
in preparation for using the same dynamic declaration feature for
simulation nodes.
Generally there shouldn't be user-visible differences, but one benefit
is that user-created socket descriptions are now visible directly in
the node editor for group nodes and group input/output nodes.
The commit contains a few changes:
- Add a node type callback for building dynamic declarations with
different arguments
- Add an `Extend` socket declaration for the "virtual" sockets used
for connecting new links
- A similar `Custom` socket declaration is used for addon-defined socket
- Simplify the node update loop to use the declaration to build update
sockets
- Replace the "group update" functions with the declaration building
- Move the node group input/output link creation to link drag operator
- Make the field status part of group node declarations
(not for group input/output nodes though)
- Some fixes for declarations to make them update and build properly
Differential Revision: https://developer.blender.org/D16850
This is part of D16858 but is also useful for other purposes.
The changes to the node declaration in this commit allow us to figure
out which fields might be evaluated on which geometries statically (without
executing the node tree). This allows for deterministic anonymous attribute
handling, which will be committed separately. Furthermore, this is necessary
for usability features that help the user to avoid creating links that don't
make sense (e.g. because a field can't be evaluated on a certain geometry).
This also allows us to better separate fields which depend or don't depend
on anonymous attributes.
The main idea is that each node defines some relations between its sockets.
There are four relations:
* Propagate relation: Indicates that attributes on a geometry input can be
propagated to a geometry output.
* Reference relation: Indicates that an output field references an inputs field.
So if the input field depends on an anonymous attribute, the output field
does as well.
* Eval relation: Indicates that an input field is evaluated on an input geometry.
* Available relation: Indicates that an output field has anonymous attributes
that are available on an output geometry.
These relations can also be computed for node groups automatically, but that
is not part of this commit.
When these declarations are built without the help of the special
builder class, it's much more convenient to set them directly rather
than with a constructor, etc. In most other situations the declarations
should be const anyway, so theoretically this doesn't affect safety too
much. Most construction of declarations should still use the builder.
This adds an explicit post processing step to node declarations.
The purpose of this is to keep the actual node declaration functions
concise by avoiding to specify redundant information. Also it improves
the separation of the creation of the declaration from using it.
Previously, all implicit inputs where stored in a centralized place.
Now the information which nodes have which implicit inputs is
stored in the nodes directly.
This patch adds support for the skip realization option of the input
descriptor. Inputs that request skip realization will not be realized on
the operation domain of the operation and will not contribute to its
computation, and consequently, they can't be a domain input.
An example is the bokeh input of the Bokeh Blur node, which is actually
a resource that is decoupled from the rest of the inputs and should not
affect or be affected by their domain.
Differential Revision: https://developer.blender.org/D15767
Reviewed By: Clement Foucault
This patch adds the core realtime compositor evaluator as well as a
compositor draw engine powered by the evaluator that operates in the
viewport. The realtime compositor is a new GPU accelerated compositor
that will be used to power the viewport compositor imminently as well as
the existing compositor in the future.
This patch only adds the evaluator and engine as an experimental
feature, the implementation of the nodes themselves will be committed
separately.
See T99210.
Differential Revision: https://developer.blender.org/D15206
Reviewed By: Clement Foucault
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
This node is a bit special in that it uses two internal sockets
for a hack for Eevee; see rBffd5e1e6acd296a187e7af016f9d7f8a9f209f87
As a result, the `SOCK_UNAVAIL` flag is exposed to socket builder API.
Reviewed By: JacquesLucke, fclem
Differential Revision: https://developer.blender.org/D13496
When dragging from the inputs of function nodes, other function
nodes wouldn't connect, because their socket declaration field types
weren't set correctly. Instead, they relied on code properly checking
the *node* declaration's `is_function_node()` method. However,
that increases complexity and requires passing the node instead of
just the socket in more places. Instead, set the proper field types
in the socket declaration during building.
Differential Revision: https://developer.blender.org/D13600
This commit adds a search menu when links are dragged above empty
space. When releasing the drag, a menu displays all compatible
sockets with the source link. The "main" sockets (usually the first)
are weighted above other sockets in the search, so they appear first
when you type the name of the node.
A few special operators for creating a reroute or a group input node
are also added to the search.
Translation is started after choosing a node so it can be placed
quickly, since users would likely adjust the position after anyway.
A small "+" is displayed next to the cursor to give a hint about this.
Further improvements are possible after this first iteration:
- Support custom node trees.
- Better drawing of items in the search menu.
- Potential tweaks to filtering of items, depending on user feedback.
Thanks to Juanfran Matheu for developing an initial patch.
Differential Revision: https://developer.blender.org/D8286
This flag is currently only used for vector sockets
so the function is limited to the vector builder.
The flag is only used by two shader nodes at the moment
and this is needed to port them over to the new socket declaration API.
Reviewed By: JacquesLucke
Differential Revision: https://developer.blender.org/D13490
Previously, to get the declaration of a socket, one had to go
through `node->declaration`. Now this indirection is not necessary
anymore. This makes it easier to add more per-socket information
into the declaration and accessing it in various places.
Currently, this system is used by socket descriptions and node warnings
for unsupported geometry component types.
This solves the issue in a more general that can also be used to solve
similar issues for other nodes in the future. Nodes can specify their
"main" socket in their declaration so that we don't have to rely on
heuristics.
Differential Revision: https://developer.blender.org/D13108
The new socket declaration api generates a surprising amount
of symbols in each translation unit where it is used. This resulted
in a measurable compile time increase.
This commit reduces the number of symbols that are generated in
each translation unit significantly. For example, in
`node_geo_distribute_points_on_faces.cc` the number of symbols
decreased from 1930 to 1335. In my tests, this results in a 5-20%
compile time speedup when this and similar files are compiled
in isolation (measured by executing the command in `compile_commands.json`).
Compiling the distribute points on faces node sped up from ~2.65s to ~2.4s.
Change the toggle to switch between an attribute and a single value to
only display for inputs that are fields, as determined statically by
the field inferencing added in rB61f3d4eb7c7db7. This means the field
inferencing must be calculated on file load, since it's used in the UI.
Differential Revision: https://developer.blender.org/D12623
This adds initial limited support for socket tooltips. It's limited
in a couple of ways for now:
* Only works when hovering over the socket shape, not when hovering
over the value in the socket.
* Only works for built-in nodes that already use the new node
declaration system. This can later be extended to support pynodes.
Those limitations are well worth it for now, given that the
implementation is quite simple and the impact on usability is quite
large. More complex updates to the layout system, that would allow
showing socket tooltips in the nodes, can be done later. With the
current implementation we can at least start writing tooltips for
geometry nodes now.
This commit already adds tooltips for the Cylinder node as an example.
Differential Revision: https://developer.blender.org/D12607
This implements the update logic for the vizualization of which
sockets pass data or constants directly, and which pass functions.
The socket shapes may still have to be updated. That should be
done separately, because it might be a bit more involved, because
socket shapes are currently linked to keyframe shapes. Currently
the circle and diamond shapes are used with the following meanings:
- Input Sockets:
- Circle: Required to be a single value.
- Diamond: This input supports fields.
- Output Sockets:
- Circle: This output is a single value.
- Diamond: This output may be a field.
Connecting a field to a circle input socket is an error, since a
field cannot be converted to a single value. If the socket shape
is a diamond with a dot in the middle, it means it is currently
a single value, but could be a field.
In addition to socket shapes, the intention is to draw node links
differently based on the field status. However, the exact method for
conveying that isn't decided yet.
Differential Revision: https://developer.blender.org/D12584
This commits adds a few common flags to `SocketDeclaration`
so that they are available for all socket types (hide label, hide
value, is multi input). This allows porting over the remaining
geometry nodes to the new declaration system.
Furthermore, this commit separates the concepts of the socket
declaration and corresponding builders. The builders are used
by nodes to declare which sockets they have (e.g. `FloatBuilder`).
The ready build socket declarations can then be consumed by
other systems such as the versioning code. Both use cases
need different APIs and those will change for independent reasons,
so it makes sense to separate the classes.
Previously, it was necessary to rebuild the node declaration
every time it was used. Now it is cached per node for easy
and fast access.
For more details on what this is, look at the comment in
`DNA_node_types.h`.
Differential Revision: https://developer.blender.org/D12471
Previously, built-in nodes had to implement "socket templates"
(`bNodeSocketTemplate`) to tell Blender which sockets they have.
It was nice that this was declarative, but this approach was way
too rigid and was cumbersome to use in many cases.
This commit starts to move us away from this rigid structure
by letting nodes implement a function that declares the sockets
the node has. Right now this is used as a direct replacement
of the "socket template" approach to keep the refactor smaller.
It's just a bit easier to read and write.
In the future we want to support more complex features like
dynamic numbers of sockets and type inferencing. Those features
will be easier to build on this new approach.
This new approach can live side by side with `bNodeSocketTemplate`
for a while. That makes it easier to update nodes one by one.
Note: In `bNodeSocketTemplate` socket identifiers were made
unique automatically. In this new approach, one has to specify
unique identifiers manually (unless the name is unique already).
Differential Revision: https://developer.blender.org/D12335
