The import nodes are considered complete enough to expose without
the experimental option. This commit removes the option so they will
be exposed in 4.5. There are still some possible future improvements,
including automatic caching, possibly exposing more input sockets,
and possibly including imported paths in the "Internal Dependencies"
panel. Those are considered non blocking though.
Pull Request: https://projects.blender.org/blender/blender/pulls/135957
This used custom data types before, which was misleading and didn't
scale well because the set of attribute types is different than the set
of grid types we can store. Now just use the grid data type, like how
the store named attribute node uses the attribute type.
This covers backward compatibility, but not forward compatibility.
Pull Request: https://projects.blender.org/blender/blender/pulls/135814
This makes specifying a legacy type for new node types optional (e.g.
`GEO_NODE_MESH_TO_CURVE`). Instead, only the `idname` is used as a stable
identifier for node types. So there is less redundancy for now.
This change helps with the decentralized definition of nodes and reduces the
number minimum number of files that need to be changed for a new node from 5 to
4. It especially helps when multiple nodes are worked on at the same time,
because the legacy type definition was very prone to have merge conflicts.
For compatibility reasons and because it's still used by existing code, the
`legacy_type` is not removed. All existing nodes keep their current
`legacy_type`. New nodes will receive an auto-incremented legacy type. It's
still necessary to give nodes unique legacy types, because some code checks if
two nodes have the same type by comparing their `legacy_type`. These types only
have to be unique at run-time though. Some randomness is used to avoid depending
on stable generated legacy types accidentally.
Pull Request: https://projects.blender.org/blender/blender/pulls/133044
This removes the second to last usage of `NOD_static_types.hh` which we intend
to remove. A nice benefit is that the idname is now finally more explicit when a
node is registered. Previously it was difficult to search for the definition of
a node in the code when one had only the idname, which is the main identifier
for nodes.
The main change is in `node_type_base`.
Pull Request: https://projects.blender.org/blender/blender/pulls/132815
As part of an effort to remove this header, reducing the need for macro/
include magic and making node definitions more independent, move
the node UI name and description definitions to each node's file.
The UI name, description, and idname are also moved to std::string
instead of char arrays.
Similar to b43e2168e3.
Pull Request: https://projects.blender.org/blender/blender/pulls/132708
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
The simulation input and output node are closely related and also share some code.
That's easier to handle if they are in the same file.
I also extracted out the code to mix geometries.
Pull Request: https://projects.blender.org/blender/blender/pulls/117713
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
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 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
Convert the vector socket from four nodes to a rotation socket, adding
versioning to insert the conversion nodes and change the default values
where necessary.
- Distribute Points on Faces
- Instance on Points
- Rotate Instances
- Transform Geometry
Implicit conversions from vectors and floats, and to vectors have been
added, though using rotation sockets directly can be faster, since converting
to and from Euler rotations is slow. Conversion nodes are not inserted
by versioning if the implicit conversions can be used.
This change is not forward compatible with 3.6, and socket values
are lost when opening 4.1 files in 4.0. The correct socket types are
added back in old versions, though newly added conversion nodes
may have to be removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/111482
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
This makes the code reusable in a few more places,
particularly by tests for a new boolean implementation
also defined in the geometry module.
It also makes the way some primitives are reused among
different nodes a bit clearer.
Pull Request: https://projects.blender.org/blender/blender/pulls/112255
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
Goals of the refactor:
* Internal support for baking individual simulation zones (not exposed in the UI yet).
* More well-defined access to simulation data in geometry nodes. Especially, it
should be more obvious where data is modified. A similar approach should also
work for the Bake node.
Previously, there were a bunch of simulation specific properties in `GeoNodesModifierData`
and then the simulation input and output nodes would have to figure out what to do with that
data. Now, there is a new `GeoNodesSimulationParams` which controls the behavior of
simulation zones. Contrary to before, different simulation zones can now be handled
independently, even if that is not really used yet. `GeoNodesSimulationParams` has to be
subclassed by a user of the geometry nodes API. The subclass controls what each simulation
input and output node does. This some of the logic that was part of the node before, into
the modifier.
The way we store simulation data is "transposed". Previously, we stored zone data per
frame, but now we store frame data per zone. This allows different zones to be more
independent. Consequently, the way the simulation cache is accessed changed. I kept
things simpler for now, avoiding many of the methods we had before, and directly
accessing the data more often which is often simple enough. This change also makes
it theoretically possible to store baked data for separate zones independently.
A downside of this is, that existing baked data can't be read anymore. We don't really
have compatibility guarantees for this format yet, so it's ok. Users will have to bake again.
The bake folder for the modifier now contains an extra subfolder for every zone.
Drawing the cached/baked frames in the timeline is less straight forward now. Currently,
it just draws the state of one of the zones, which usually is identical to that of all other
zones. This will change in the future though, and then the timeline drawing also needs
some new UI work.
Pull Request: https://projects.blender.org/blender/blender/pulls/111623
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.
The goal here is to reduce the number of files that need to be edited when
adding a new node. To register a node, one currently has to add a line to
`node_geometry_register.cc` and `node_geometry_register.hh` (for geometry
nodes). Those files can be generated automatically.
There is a new `NOD_REGISTER_NODE` macro that nodes can use to register
themselves. The macro is then discovered by `discover_nodes.py` that generates
code that calls all the registration functions. The script also works when the
register functions are in arbitrary namespaces. This allows simplifying the node
code as well.
In the past I tried a few times to get auto-registration working without resorting to
code generation, but that never ended up working. The general idea for that would
be to use non-trivial initialization for static variables. The issue always ends up
being that the linker just discards those variables, because they are unused and it
doesn't care if there are side effects in the initialization.
Related discussion regarding using Python for code generation:
https://devtalk.blender.org/t/code-generation-with-python/30558
Pull Request: https://projects.blender.org/blender/blender/pulls/110686
Add three new nodes for operations and inputs specific to
node group operators.
- **Selection** Whether elements are selected in the viewport
- **Set Selection** Sets the edit/sculpt selection, on the point,
face, or curve domains
- **3D Cursor** Gives the location and rotation of the 3D cursor,
in the local space of the modified object.
- **Face Set** The face set value from mesh sculpt mode,
and whether the attribute exists.
- **Set Face Set** Set sculpt face set values.
In the add menu and search, the nodes are only visible in the
"Tool" context of the geometry node editor. They also give
errors when executed by a modifier.
Pull Request: https://projects.blender.org/blender/blender/pulls/109517
This adds support for running a set of nodes repeatedly. The number
of iterations can be controlled dynamically as an input of the repeat
zone. The repeat zone can be added in via the search or from the
Add > Utilities menu.
The main use case is to replace long repetitive node chains with a more
flexible alternative. Technically, repeat zones can also be used for
many other use cases. However, due to their serial nature, performance
is very sub-optimal when they are used to solve problems that could
be processed in parallel. Better solutions for such use cases will
be worked on separately.
Repeat zones are similar to simulation zones. The major difference is
that they have no concept of time and are always evaluated entirely in
the current frame, while in simulations only a single iteration is
evaluated per frame.
Stopping the repetition early using a dynamic condition is not yet
supported. "Break" functionality can be implemented manually using
Switch nodes in the loop for now. It's likely that this functionality
will be built into the repeat zone in the future.
For now, things are kept more simple.
Remaining Todos after this first version:
* Improve socket inspection and viewer node support. Currently, only
the first iteration is taken into account for socket inspection
and the viewer.
* Make loop evaluation more lazy. Currently, the evaluation is eager,
meaning that it evaluates some nodes even though their output may not
be required.
Pull Request: https://projects.blender.org/blender/blender/pulls/109164
When we don't need to preserve a persistent cache, we can use
the geometry from the last frame directly rather than copying it.
Though implicit lets us avoid copying large data arrays when they
aren't changed, this can still give a large improvement for something
like particle simulation where the majority of the data was copied
every frame.
Pull Request: https://projects.blender.org/blender/blender/pulls/109742
