We had a short discussion on this change. "Grease Pencil Layer" is
just a bit too long, especially in the UI. Even though "Layer" might be
ambiguous, it shouldn't be in the context of geometry nodes. There are
currently no other "Layers" and if there were, using the same domain
name could be fine (just like we reuse the point domain for e.g. vertices
in meshes and control points in curves).
This also renames the internal enum to `ATTR_DOMAIN_LAYER`
Pull Request: https://projects.blender.org/blender/blender/pulls/113589
This implements the core changes for this design: https://devtalk.blender.org/t/grease-pencil-integration-into-geometry-nodes/31220
The changes include:
* Add `CustomData` for layer attributes
* Add attribute support for the `GreasePencilComponent` to read/write layer attributes. Also introduces a `Layer` domain.
* Implement a `GreasePencilLayerFieldContext` and make `GeometryFieldContext` work with grease pencil layers.
* Implement `Set Position` node for `Grease Pencil`.
Note: These changes are only accessible/visible with the `Grease Pencil 3.0` experimental flag enabled.
Co-authored-by: Jacques Lucke <jacques@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/112535
The goal here is to make it easier to use the socket declaration builder
for cases where the actual socket type is not known at compile time.
For that purpose, all the methods that are not dependent on the specific
socket type are moved to the base socket declaration builder.
A nice side effect of this is reduced templated boilerplate and that more
code can be moved out of the header.
With this patch, one is now forced to put type specific method calls before
generic method calls in a chain. For example `.default_value(...).supports_field()`
instead of `supports_field().default_value(...)`. In theory, we could keep
support for both orders but that would involve a lot of additional boilerplate
code. Enforcing this order is simple enough. Note that this limitation only
applies when chaining multiple method calls. This is still possible:
```
auto &decl = b.add_input<decl::Vector>("Value");
decl.supports_field();
decl.default_value(...);
```
Pull Request: https://projects.blender.org/blender/blender/pulls/113410
`iota` is name that has no meaning, it's not an acronym or initialism.
It's usually very cryptic when I come across it. Replacing it with a
specialized function makes the code more readible.
This idea is of remapping parameters of lazy-functions is useful
not only for the repeat zone. For example, it could be used for the
for-each zone as well.
Also, moving it to a more general place indicates that there is no
repeat-zone specific stuff in it.
This makes it easier to read generated lazy-function graphs, especially when
there are zones or group nodes, because the socket identifiers on those
are some generated internal name.
The goal of this refactor is to reduce the amount of boilerplate code that is
necessary to have a dynamic number of sockets on nodes. This is achieved
by making the code more reusable. Currently, only the simulation and repeat
zone nodes make use of this. However, even with just those two, the amount
of code is reduced already. The benefit of this refactor will become even more
significant as more nodes support a dynamic number of sockets. For example,
the bake node and for-each zone will also benefit from this.
We could probably make some of the utility functions non-templates using type
erasure. This could reduce the compilation overhead when the number of nodes
with item arrays increases. The main reason for why everything is templated
now is that it made this refactor easier. Without this patch, all the code was
essentially "manually templated". So the implementations look still similar to
before now, just that concrete types are replaced with template parameters.
No user-visible changes are expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/113114
Previously, the geometry nodes modifier was converting the
viewer path to a compute context at the same time as it was
setting up side effect nodes for the geometry nodes evaluation.
Now, this is changed to be a two step process. First, the viewer
path is converted to the corresponding compute context.
Afterwards, a separate function sets side effect nodes up so
that the given node in the given compute context will be evaluated.
This has three main benefits:
* More obvious separation of concerns.
* Can reuse the code that maps a viewer path element to a compute
context already.
* With gizmo nodes (#112677), it may become necessary to add side
effect nodes based on a compute context, but without having a
corresponding viewer path.
Previously, it was only possible to inspect the data from the first iteration. That
applied to both, the viewer node as well as socket inspection. Now, there is a
new `Inspection Index` setting in the zone properties. It specifies which iteration
should be used by the inspection features.
In theory we could support features like counting the index from the end, but
that can be done separately as well, as it likely requires more UI.
Pull Request: https://projects.blender.org/blender/blender/pulls/112818
Inlined sockets in the same vertical space are no longer supported.
This removes `input_output` socket declarations, the inlining feature in
node drawing, and the `Both` option for node group interface sockets.
Versioning code splits existing node group sockets into individual
sockets again. Unfortunately some links may get lost in versioning files
using the feature, because of an unnoticed bug: Socket identifiers have
to be unique in the node group items list but inlined input/output
sockets have the same identifier. This still works for most situations
because uniqueness is only required within input/output lists. Creating
proper unique identifiers will discard any link from the previous output
socket. This cannot easily be fixed without `after_linking` versioning
code, which should be avoided.
Pull Request: https://projects.blender.org/blender/blender/pulls/112560
The goal is to make the evaluation of repeat zones more efficient by making
use of the lazy-function evaluation system. Performance is improved in two ways:
* Unnecessary nodes are not evaluated anymore. E.g. if a repeat zone outputs two
geometries but only one of those is actually used, the other one will not be
computed anymore.
* Support evaluating different iteration indices at the same time on different threads.
It is possible that some uses of repeat zones become slower with this refactor,
especially when each iteration does very little work and there are a lot of iterations.
The old implementation was not optimized for this use case either but now there
is a bit more overhead constant overhead per iteration than before.
On the bright side, this change can result in some very significant speedups when
some computations can be skipped. See #112421 for some example setups.
There is one todo comment for adding back-links for socket usages. Properly linking
those up can result in better (shorter) life-times for anonymous attributes. Even without
that, performance is already better than before.
The implementation reuses the existing lazy-function graph system for the repeat
zone, by building a dynamically sized graph based on the number of iterations.
Building a lazy-function graph makes it possible to use the lazyness and multi-threading
features of the lazy-function graph executor. This is much easier than reimplementing
this behavior for repeat zones specifically (hence there was only single-threaded eager
execution before).
Pull Request: https://projects.blender.org/blender/blender/pulls/112421
The issue was that the `user_data` pointer in the local user data
is not necessarily valid, because a different user-data might be
passed in when a lazy-function is called a second time (it's semantically
the same user-data but, might have a different pointer).
The solution is to not keep around the dangling pointer but to pass
it in when it is actually needed. I still keep the old constructor of the
local-user-data, because more stuff might be added to it, that needs
the user-data, as was the case in the past already (before 142541c27).
The goal is to reduce redundancy by abstracting over the different types of node
tree zones. This makes it easier to add new zone types and makes the intend of
code more clear. For example, now it is more obvious what code deals with zones
in general and what does simulation specific things.
Pull Request: https://projects.blender.org/blender/blender/pulls/112531
The main goal of this refactor is to simplify how a geometry node group is executed.
Previously, there was duplicated logic that turned the lazy-function graph of a node
group into a single lazy-function. Now this is done only in one place and others can
just execute the lazy-function directly, without having to worry about the underlying graph.
Pull Request: https://projects.blender.org/blender/blender/pulls/112482
Goals of the refactor:
* Simplify adding (named) graph inputs and outputs.
* Add ability to refer to a graph input or output with an index.
* Get rid of the "dummy" terminology which doesn't really help.
Previously, one would add "dummy nodes" which can then serve as input
and output nodes of the graph. Now one directly adds input and outputs
using `Graph.add_input` and `Graph.add_output`. There is one interface
node that contains all inputs and another one that contains all outputs.
Being able to refer to a graph input or output with an index makes it
more efficient to implement some algorithms. E.g. one could have a
bit span for a socket that contains all the information what graph
inputs this socket depends on.
Pull Request: https://projects.blender.org/blender/blender/pulls/112474
This is a light weight solution to passing in some extra context into
a lazy-function that is invoked by the graph executor.
The new functionality is used by #112421.
This makes the code for creating a lazy-function for the body
of a zone more reusable. Currently, it is only used by the repeat
zone, but in the future the same could be used for simulations
and for-each zones.
Currently, we create a logger for every compute context that is evaluated,
even when we don't actually log anything in that context (due to other
optimizations). Now, the logger is not created eagerly anymore.
This can be especially benefitial when there are many compute contexts
that should not log anything, e.g. if there is a repeat zone with many iterations.
In an extrem case I measured a speedup for the modifier evaluation
from 24ms to 14ms.
Declarations can use the `add_input_output` method to create a combined input/output socket. The drawing code supports moving sockets up one vertical slot to align them with the predecessor.
Closes#112235
Pull Request: https://projects.blender.org/blender/blender/pulls/112250
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
The declaration code for node groups was relying on `bNodeSocketType` to
provide the subtype of a socket. This worked before node panels
(#111348) since the interface sockets had a fully refined typeinfo.
Now the interface sockets use only the base typeinfo and the socket
subtype is stored in the interface data itself.
Pull Request: https://projects.blender.org/blender/blender/pulls/112286
Now that specific menus can be searched directly (see 7f9d51853c),
there is no need to maintain separate search functionality for adding
nodes. This PR removes the add node search. In a way this brings us
closer to the `NodeItem` situation before, but the setup is more
flexible since the menus are more standard and easier to customize.
In the few ways we customized the node search items before, this gives
us the same results as before. Overall the searching is less flexible,
but I think that is just a tradeoff we have to accept for the simplicity
of searching menus. In the future menus could be made more dynamic,
with each builtin node's menu path stored on the node type, similar to
assets. That might be a nice compromise. In the meantime this code
is just dead weight.
Pull Request: https://projects.blender.org/blender/blender/pulls/112056
Node groups already have panels, but they modify the node declaration
directly, which is not something we want to do for builtin nodes. For
those the `PanelDeclarationBuilder` should be used.
`PanelDeclarationBuilder` has `add_input`/`add_output` methods just like `NodeDeclarationBuilder`. Adding sockets to a panel increases its size by one. All sockets must be added in order: Adding sockets or panels to the root `NodeDeclarationBuilder` after a panel will complete the panel and adding more sockets to it after that will fail. This is to enforce a stable item order where indices don't change after adding a socket, which is important for things like field dependencies.
Example:
```cpp
static void node_declare(NodeDeclarationBuilder &b)
{
// Currently this is necessary to enable custom layouts and panels.
// Will go away eventually when most nodes uses custom layout.
b.use_custom_socket_order();
// Create a panel.
PanelDeclarationBuilder &pb = b.add_panel("My Panel").description("A demo panel").default_closed(true);
// Add to the panel instead of the root layout.
pb.add_input<decl::Color>("Color").default_value({0.8f, 0.8f, 0.8f, 1.0f});
pb.add_input<decl::Float>("Weight").unavailable();
// Continue socket declarations as usual.
b.add_output<decl::Shader>("BSDF");
// !!! Warning: continuing the panel after other items is not allowed and will show an error.
pb.add_output<decl::Float>("Bad Socket");
}
```
Pull Request: https://projects.blender.org/blender/blender/pulls/111695
This adds a new Skip input to the Simulation Output node (design task: #112082).
It is a convenience feature that makes it easy to conditionally forward the
output of the Simulation Input node to the Simulation Output node, without the
need for potentially multiple Switch nodes. When Skip is enabled, the other inputs
of the Simulation Output node are not evaluated, i.e. the nodes in the simulation
zone are ignored.
The implementation adds this new functionality directly to the `LazyFunction`
of the Simulation Output node. It has new inputs that are linked directly
to the Simulation Input node, so that the simulation state can be forwarded.
Pull Request: https://projects.blender.org/blender/blender/pulls/112140
Node group sockets can be set to "both" for input/output, generating
two socket declarations in the same panel. Panel size was calculated
using only the items count, which is <= the actual declarations count.
This patch calculates actual declarations count as the panel size.
Panel size variable renamed to `num_child_decls` to distinguish from
`num_items`.
Pull Request: https://projects.blender.org/blender/blender/pulls/112013
There are a couple of functions that create rna pointers. For example
`RNA_main_pointer_create` and `RNA_pointer_create`. Currently, those
take an output parameter `r_ptr` as last argument. This patch changes
it so that the functions actually return a` PointerRNA` instead of using
the output parameters.
This has a few benefits:
* Output parameters should only be used when there is an actual benefit.
Otherwise, one should default to returning the value.
* It's simpler to use the API in the large majority of cases (note that this
patch reduces the number of lines of code).
* It allows the `PointerRNA` to be const on the call-site, if that is desired.
No performance regression has been measured in production files.
If one of these functions happened to be called in a hot loop where
there is a regression, the solution should be to use an inline function
there which allows the compiler to optimize it even better.
Pull Request: https://projects.blender.org/blender/blender/pulls/111976
