Functions for convert between the color types and ostream support are
now outside the classes.
Many files were changed to fix cases where direct includes for headers
were missing.
Pull Request: https://projects.blender.org/blender/blender/pulls/145756
Previously, we always just used `int` when dealing with menu values on the C++
side. It's currently the only type where we have the same base type (`int`) for
two different socket types (integer and menu sockets). This has some downsides:
* It requires special cases in some places.
* There is no function from static base type to socket type (which is useful for
some utilities like `SocketValueVariant`).
* It implicitly allows operations on menu values that shouldn't be allowed such
as arithmetic operations and conversions to and from other types.
This patch adds a new `MenuValue` type that is used for menu sockets in Geometry
Nodes and the (CPU) Compositor, clarifying the distinction between integer and
menu values.
Pull Request: https://projects.blender.org/blender/blender/pulls/144476
Now that every socket type uses `SocketValueVariant` since #144355, the
parameter access code can be simplified a bit.
This also adds a new `GeoNodesMultiInput<T>` type that's used to access the list
of inputs value multi-input sockets.
Pull Request: https://projects.blender.org/blender/blender/pulls/144409
This includes a new list structure type and socket shape, a node
to create lists, a node to retrieve values from lists, and a node to
retrieve the length of lists. It also implements multi-function support
so that function nodes work on lists.
There are three nodes included in this PR.
- **List** Creates a list of elements with a given size. The values
are computed with a field that can use the index as an input.
- **Get List Item** A field node that retrieves an element from a
a list at a given index. The index input is dynamic, so if the input
is a list, the output will be a list too.
- **List Length** Just gives the length of a list.
When a function node is used with multiple list inputs, the shorter
lists are repeated to extend it to the length of the longest.
The list nodes and structure type are hidden behind an experimental
feature until we can be sure they're useful for an actual use case.
Pull Request: https://projects.blender.org/blender/blender/pulls/140679
This extends the API for bundles in two main ways:
* Adds support for working with paths to reference nested bundles directly.
* Adds support for typed add/lookup, also taking into account implicit conversions.
Some unit tests have been added as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/142942
So far, only node group were able to have menu input sockets. Built-in nodes did
not support them. Currently, all menus of built-in nodes are stored on the node
instead of on the sockets. This limits their flexibility because it's not
possible to expose these inputs.
This patch adds initial support for having menu inputs in built-in nodes. For
testing purposes, it also changes a couple built-in nodes to use an input socket
instead of a node property: Points to Volume, Transform Geometry, Triangulate,
Volume to Mesh and Match String.
### Compatibility
Forward and backward compatibility is maintained where possible (it's not
possible when the menu input is linked in 5.0). The overall compatibility
approach is the same as what was done for the compositor with two differences:
there are no wrapper RNA properties (not necessary for 5.0, those were removed
for the compositor already too), no need to version animation (animation on the
menu properties was already disabled).
This also makes menu sockets not animatable in general which is kind of brittle
(e.g. doesn't properly update when the menu definition changes). To animate a
menu it's better to animate an integer and to drive an index switch with it.
### Which nodes to update?
Many existing menu properties can become sockets, but it's currently not the
intention to convert all of them. In some cases, converting them might restrict
future improvements too much. This mainly affects Math nodes.
Other existing nodes should be updated but are a bit more tricky to update for
different reasons:
* We don't support dynamic output visibility yet. This is something I'll need to
look into at some point.
* They are shared with shader/compositor nodes, which may be more limited in
what can become a socket.
* There may be performance implications unless extra special cases are
implemented, especially for multi-function nodes.
* Some nodes use socket renaming instead of dynamic socket visibility which
isn't something we support more generally yet.
### Implementation
The core implementation is fairly straight forward. The heavy lifting is done by
the existing socket visibility inferencing. There is a new simple API that
allows individual nodes to implement custom input-usage-rules based on other
inputs in a decentralized way.
In most cases, the nodes to update just have a single menu, so there is a new
node-declaration utility that links a socket to a specific value of the menu
input. This internally handles the usage inferencing as well as making the
socket available when using link-drag-search.
In the modified nodes, I also had to explicitly set the "main input" now which
is used when inserting the node in a link. The automatic behavior doesn't work
currently when the first input is a menu. This is something we'll have to solve
more generally at some point but is out of scope for this patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/140705
Previously, there was the issue that `SocketValueVariant` had a constructor that
took a forwarding reference as parameter. This was problematic, because this
could potentially hide copy/move constructors which is not intentional. This
patch makes sure that these special constructors are not overridden and adds two
static utility functions to make sure it's still straight forward to construct
the `SocketValueVariant` on a single line.
Clangd also warned about this case.
Pull Request: https://projects.blender.org/blender/blender/pulls/140842
Previously, the `UserData` and `LocalUserData` classes were only supposed to be
used by the lazy-function system. However, they are generic enough so that they
can also be used by the multi-function system. Therefore, this patch extracts
them into a separate header that can be used in both evaluation systems.
I'm doing this in preparation for being able to pass the geometry nodes logger
to multi-functions, to be able to report errors from there.
Pull Request: https://projects.blender.org/blender/blender/pulls/138861
This implements bundles and closures which are described in more detail in this
blog post: https://code.blender.org/2024/11/geometry-nodes-workshop-october-2024/
tl;dr:
* Bundles are containers that allow storing multiple socket values in a single
value. Each value in the bundle is identified by a name. Bundles can be
nested.
* Closures are functions that are created with the Closure Zone and can be
evaluated with the Evaluate Closure node.
To use the patch, the `Bundle and Closure Nodes` experimental feature has to be
enabled. This is necessary, because these features are not fully done yet and
still need iterations to improve the workflow before they can be officially
released. These iterations are easier to do in `main` than in a separate branch
though. That's because this patch is quite large and somewhat prone to merge
conflicts. Also other work we want to do, depends on this.
This adds the following new nodes:
* Combine Bundle: can pack multiple values into one.
* Separate Bundle: extracts values from a bundle.
* Closure Zone: outputs a closure zone for use in the `Evaluate Closure` node.
* Evaluate Closure: evaluates the passed in closure.
Things that will be added soon after this lands:
* Fields in bundles and closures. The way this is done changes with #134811, so
I rather implement this once both are in `main`.
* UI features for keeping sockets in sync (right now there are warnings only).
One bigger issue is the limited support for lazyness. For example, all inputs of
a Combine Bundle node will be evaluated, even if they are not all needed. The
same is true for all captured values of a closure. This is a deeper limitation
that needs to be resolved at some point. This will likely be done after an
initial version of this patch is done.
Pull Request: https://projects.blender.org/blender/blender/pulls/128340
Previously, the code would assert in `BLI_fopen` when the path is relative.
There are two main options to make the path absolute:
1. Always use the path of the current .blend file as base.
2. Is the path of the .blend file "owns" the current node as base. So when
the Import node is part of a linked node tree, the path of the linked .blend
file is used as base.
Both options are useful depending on the specific use-case, but the latter
seems more consistent with other places in Blender. For more advanced
functionality, we might need nodes that give the current .blend file path
and one node to join paths.
Pull Request: https://projects.blender.org/blender/blender/pulls/134794
There is not really a good definition for what an "attribute kind". There are
many possibilities, it could include domain, type, geometry type, default value,
usage, ...
So it's better not to use this generic name. With the current name, one always
has to look at the definition again to be sure what it contains and what it does
not.
The name `AttributeDomainAndType` is way more explicit and does not have the
same problems. It's a bit longer, but that does not seem to be a problem in the
places where we use it.
Pull Request: https://projects.blender.org/blender/blender/pulls/130505
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
This improve the API in multiple aspects:
* No need for an additional `lookup` call to get the current attribute. This
would internally iterate over all attributes again. This leads to O(n^2)
behavior. Note that there are still other reasons for O(n^2) behavior when
processing attributes (where n is the number of attributes).
* Remove the need to return a value from the iteration code to indicate that the
iteration should continue. This is now the default behavior. The iteration can
still be stopped by calling `iter.stop()`.
* Easier access to `is_builtin` property.
* Iterator callback only has a single parameter instead of two (of which one is
sometimes unused).
Pull Request: https://projects.blender.org/blender/blender/pulls/128128
This introduces the concept of an #AttributeFilter. It's used to tell a geometry
algorithm which attributes it should process/propagate and which can be ignored.
We already had something similar before named
`AnonymousAttributePropagationInfo`. However, as the name implies, this was
specific to anonymous attributes. This had some downsides:
* A lot of code had to be aware of the concept of anonymous attributes even if
it did nothing special with anonymous attributes.
* For non-anonymous attributes we often had a separate `Set<std::string> skip`
parameter. It's not nice to have to pass two kinds of filters around and to
have to construct a `Set<std::string>` in many cases.
`AttributeFilter` solves both of these downsides.
Technically, `AttributeFilter` could also just be a `FunctionRef<bool(StringRef
attribute_name)>`, but that also has some issues:
* The `bool` return value is often ambiguous, i.e. it's not clear if it means
that the attribute should be processed or not. Using an enum works better.
* Passing function refs around and combining them works, but can very easily
lead to dangling references.
* The default value of a `FunctionRef` is "empty", i.e. it can't be called. It's
generally more nice to not have a special case for the default value. Now the
default `AttributeFilter` propagates all attributes without any extra handling
on the call-site.
Pull Request: https://projects.blender.org/blender/blender/pulls/127155
Previously, the `AttributeIDRef` wrapper was needed because it also had to
contain a pointer to an `AnonymousAttributeID`. However, since
b279a6d703 this is not necessary anymore.
Therefore we can use "raw" `StringRef` now which reduces the mental overhead
when working with attributes and also simplifies code.
Pull Request: https://projects.blender.org/blender/blender/pulls/127140
This removes `AnonymousAttributeID` which was "attached" to every anonymous
attribute before. It adds more complexity than is justified for its
functionality.
It was originally introduced to keep the reference count of the anonymous
attribute so that it can be deleted automatically when the attribute is not
referenced anymore. For quite some time we have had deterministic attribute
life-times though which don't rely on the reference count anymore.
Anonymous attributes are sometimes shown in the UI as "friendly looking" string
like `"UV Map" from Cube`. Some information necessary for this was also stored
in `AnonymousAttributeID`. However, this can also be solved differently.
Specifically, this functionality has now been added directly to
`AttributeFieldInput`.
This refactor also allows removing `AttributeIDRef` which was mainly introduced
because we had to keep the `AnonymousAttributeID` attached with the attribute
name. Just using simple string types to identify attributes can reduce the
mental overhead quite significantly. This will be done as a separate refactor
though.
Pull Request: https://projects.blender.org/blender/blender/pulls/127081
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
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
This is the initial implementation for the volume grid sockets that has been
discussed during the November 2023 geometry nodes workshop.
It adds initial support for passing volume grids around in sockets. Furthermore,
it adds two new nodes. Both are initially hidden under the "New Volume Nodes"
experimental option until we have a few mode nodes.
* **Get Named Grid**: Gets or extracts a volume grid from a volume geometry
based on the grid's name.
* **Store Named Grid**: Puts a volume grid back into a volume with a name.
`SocketValueVariant` is extended to support grids besides single values and fields.
Next steps:
* Implement grid socket shape and inferencing (currently, they just look like
single values).
* Add implicit conversions between grid types.
* Implement nodes that operate on the grids (#116021).
* Improved spreadsheet and viewer support.
Links:
* https://devtalk.blender.org/t/volumes-in-geometry-nodes-proposal/31917
* https://devtalk.blender.org/t/2023-11-06-geometry-nodes-workshop-notes/32007#volumes-3
Co-authored-by: Jacques Lucke <jacques@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/115270
Each value is now out of the global namespace, so they can be shorter
and easier to read. Most of this commit just adds the necessary casting
and namespace specification. `enum class` can be forward declared since
it has a specified size. We will make use of that in the next commit.
This refactors `SocketValueVariant` with the following goals in mind:
* Support type erasure so that not all users of `SocketValueVariant` have
to know about all the types sockets can have.
* Move towards supporting "rainbow sockets" which are sockets whoose
type is only known at run-time.
* Reduce complexity when dealing with socket values in general. Previously,
one had to use `SocketValueVariantCPPType` a lot to manage uninitialized
memory. This is better abstracted away now.
One related change that I had to do that I didn't see coming at first was that
I had to refactor `set_default_remaining_outputs` because now the default value
of a `SocketValueVariant` would not contain any value. Previously, it was
initialized the zero-value of the template parameter. Similarly, I had to change
how implicit conversions are created, because comparing the `CPPType` of linked
sockets was not enough anymore to determine if a conversion is necessary.
We could potentially use `SocketValueVariant` for the remaining socket types in the
future as well. Not entirely sure if that helps yet. `SocketValueVariant` can easily be
adapted to make that work though. That would also justify the name
"SocketValueVariant" better.
Pull Request: https://projects.blender.org/blender/blender/pulls/116231
Doing this in preparation for also supporting volume
grids in the same type (#115270).
At some point we could also actually use an `std::variant` in this
type, but that would change behavior without futher changes.
NDEBUG is part of the C standard and disables asserts. Only this will
now be used to decide if asserts are enabled.
DEBUG was a Blender specific define, that has now been removed.
_DEBUG is a Visual Studio define for builds in Debug configuration.
Blender defines this for all platforms. This is still used in a few
places in the draw code, and in external libraries Bullet and Mantaflow.
Pull Request: https://projects.blender.org/blender/blender/pulls/115774
This avoids some duplication between the modifier and operator evaluation
contexts and also makes it easier to make independent from a specific
evaluation context (so e.g. the simulation nodes code shouldn't care whether
it's used from a modifier or operator.
Pull Request: https://projects.blender.org/blender/blender/pulls/115512
This struct is currently defined in the `functions` module but not actually used there. It's only used by the geometry nodes module, with an indirect dependency from blenkernel via simulation zone baking. This scope is problematic when adding grids as socket data, which should not be part of the functions module.
The `ValueOrField` struct is now moved to blenkernel, so it can be more easily extended to other kinds of data that might be passed around by geometry nodes sockets in future. No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/115087
This patch adds the ability for users to expand the grease pencil component in the spreadsheet and see the values for each `CurvesGeometry` in each layer.
It also makes it so that all the geometry components can be expanded for consistency.
Pull Request: https://projects.blender.org/blender/blender/pulls/113507
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 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).
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.
Include counts of some headers while making full blender build:
- BLI_color.hh 1771 -> 1718
- BLI_math_color.h 1828 -> 1783
- BLI_math_vector.hh 496 -> 405
- BLI_index_mask.hh 1341 -> 1267
- BLI_task.hh 958 -> 903
- BLI_generic_virtual_array.hh 509 -> 435
- IMB_colormanagement.h 437 -> 130
- GPU_texture.h 806 -> 780
- FN_multi_function.hh 331 -> 257
Note: DNA_node_tree_interface_types.h needs color include only
for the currently unused (but soon to be used) socket_color function.
Future step is to figure out how to include
DNA_node_tree_interface_types.h less.
Pull Request: #111113
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
Move `GeometrySet` and `GeometryComponent` and subclasses
to the `blender::bke` namespace. This wasn't done earlier since
these were one of the first C++ classes used throughout Blender,
but now it is common.
Also remove the now-unnecessary C-header, since all users of
the geometry set header are now in C++.
Pull Request: https://projects.blender.org/blender/blender/pulls/109020
Add a quaternion rotation socket type, and using the recently added
rotation attribute type, support the type in most of the multi-type
geometry nodes, and modifier attribute inputs and outputs.
The socket is still exposed with an XYZ Euler default value.
In the future we can add modes to this rotation value similar
to object rotations.
Rotation values have no implicit conversions to other types.
Nodes to convert to and from rotation values will be added
in a follow-up commit.
For now, the new socket type is hidden behind and experimental
option, because we haven't chosen the final color for it yet.
Pull Request: https://projects.blender.org/blender/blender/pulls/108903
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
The main goal here is to reduce the number of times thread-local data has
to be looked up using e.g. `EnumerableThreadSpecific.local()`. While this
isn't a bottleneck in many cases, it is when the action performed on the local
data is very short and that happens very often (e.g. logging used sockets
during geometry nodes evaluation).
The solution is to simply pass the thread-local data as parameter to many
functions that use it, instead of looking it up in those functions which
generally is more costly.
The lazy-function graph executor now only looks up the local data if
it knows that it might be on a new thread, otherwise it uses the local data
retrieved earlier.
Alongside with `UserData` there is `LocalUserData` now. This allows users
of the lazy-function evaluation (such as geometry nodes) to have custom
thread-local data that is passed to all the lazy-functions automatically.
This is used for logging now.
Many nodes output anonymous attributes (e.g. the top selection in the
Cylinder node). The actual data is only contained in the geometry output
though. The field output just contains a reference to this data (essentially
just the generated name of an attribute). This data can be output even
without computing the geometry itself.
As of right now, this only simplifies the code a bit, but does not have a
bigger impact, because to use the anonymous attribute, you always need
the geometry anyway. However, with the upcoming simulation nodes,
it's possible to create the anonymous attribute in one frame and to access
it in another frame. In the other frame we only need the anonymous
attribute reference and don't have to create the actual geometry again.
Skipping creating the actual attribute on the geometry can have a
significant performance benefit.
This changes the Switch node so that it is implemented directly as a lazy-function,
instead of as a normal geometry node which uses `GeoNodeExecParams`. This improves
the design of the layered execution api, where different nodes can be implemented
at a proper different abstraction level. The simplest kinds of nodes are implemented
as multi-function, then there is `GeoNodeExecParams` and more specialized nodes are
implemented as lazy-function. The switch node is special in the sense that it currently
needs extra behavior in the lazy-function graph generation anyway.
`GeoNodeExecParams` can be simplified as well, because the Switch node was the only
one that used the `lazy_` methods.
We could consider adding back lazy-input functionality to normal geometry nodes
as it becomes necessary. Ideally, that could be integrated with the node declaration.
Pull Request: https://projects.blender.org/blender/blender/pulls/105696
