Problem Description Generic algorithms like join_geometries and realize_instances create attribute data when merging geometries where one part has an attribute and the other doesn't. Example: copying a default Grease Pencil stroke with no explicit "hardness" attribute into another curves geometry. The "hardness" gets initialized to 0 but should be 1. https://projects.blender.org/blender/blender/issues/120297 Workaround Least intrusive solution for now: check attributes with known non-zero default values and initialize them before the join. This avoid the initialization to zero as the default attribute value. Problem: This recreates much of the recursion logic for realizing instances, defeating the purpose of a generic function and adding lots of opportunity for error. General Solution Define attribute defaults as an optional part of the attribute declaration.

Problem Statement Samples inside a mesh should follow the deformation of the mesh volume. Conventional Solution Mesh Deform Modifier Slow preprocessing required. Performance determined by both cage resolution and sample count. Proposed Method

Node socket types are mostly static, but some aspects of it are dynamically inferred. Field Type Inference Field Types in geometry nodes are the main example right now: Whether a socket represents a single value, a field, or either of these (undecided) is determined during node tree updates (update_field_inferencing). This information is used to show invalid field connections (field -> single value), which are marked as invalid links[^1]. In the case of field evaluation the execution code itself handles invalid connections without relying on the preprocessing step: if a single-value node input is connected to a field source it will simply receive the default value of zero when reading that input. This may not be desirable if a value of zero could have unintended consequences. The execution system may need to be more strict about violated type constraints and disable parts of the execution accordingly. Data Sockets Field sockets create virtual arrays based on the context in which they are evaluated. An field input will either be available in the context and output an array of the expected size, or simply return a default value if they can't be used in the context.

Make volumes in geometry nodes more useful and flexible. [ ] Incorporate feedback from Jacques, Hans, Dalai [ ] Separate out examples and steps that require work beyond the MVP: Fluid and hair sim need a few specialized nodes. [ ] Better illustration for "individual grids in volumes" vs. Volume geometry component. left->right train of thought, "there are multiple grids in the volume, but only one volume output" [ ] Change node design for mesh/point conversion to include volume input+output (discussed in chat) [ ] Describe meaning of position node in volume context [ ] Picture comparing different mesh/point conversion resolution modes (Size, Amount, Copy) [ ] Design a new grid resolution option to facilitate shared transforms between grids.

A proposal for making complex node trees customizable using node groups parameters. Node assets that are supposed to be used as building blocks require detail knowledge to tweak their internals. Some parameters can be exposed on the modifier level, but extending a system requires a different approach, as will be demonstrated below. This proposal describes a mechanism to allow users to specify node groups at the highest level of a node asset, which are then used inside the asset without requiring users to touch the asset internals themselves. The modifier stack for node assets and its limitations Simon Thommes recently published the first set of hair hair assets to be shipped with Blender. Simon breaks down the hair workflow into separate modifiers. This relies a lot on the fact that modifiers can be applied as a single self-contained step one after the other.

Function sockets are single-valued (no fields). This should keep overhead from type checking and dispatching to a minimum. That does not mean function sockets cannot take and return fields, it just means the function itself is the same for all elements of a field. Data flow for functions in geometry nodes flowchart G[Node Tree]:::data F[Default Bindings]:::data G --> E([bind]):::op F --> E E --> D[Closure]:::data D -->|passed through the node tree| B([evaluate]):::op