From the nodes' description: "Retrieve the object that contains
the geometry nodes modifier currently being executed". This was
discussed in the most recent geometry nodes module meeting.
Because the node allows you to retrieve the position of the modifier
object, it has to add a depsgraph relation to object transform.
Expect that modifiers will be reevaluated when moving the object.
In the future, better static analysis of node trees could make this
check smarter.
Differential Revision: https://developer.blender.org/D16037
We expect some builtin attributes to have positive values or values
within a certain range, but currently there some cases where users
can set attributes to arbitrary values: the store named attribute node,
and the output attributes of the geometry nodes modifier. The set
material index node also needs validation.
This patch adds an `AttributeValidator` to the attribute API, which
can be used to correct values from these untrusted inputs if necessary.
As an alternative to D15548, this approach makes it much easier to
understand when validation is being applied, without the need to add
arguments to every attribute API method or complicate the virtual
array system.
Currently validation is provided with a multi-function. That integrates
well with the field evaluations that set these values now, but it could
be wrapped to be friendlier to other areas of Blender in the future.
The Python API is not handled here either. Currently I would prefer to
wait until we can integrate the C++ and C attribute APIs better before
addressing that.
Fixes T100952
Differential Revision: https://developer.blender.org/D15990
This reduces logging overhead. The performance difference is only
significant when there are many fast nodes. In my test file with many
math nodes, the performance improved from 720ms to 630ms.
This refactors the geometry nodes evaluation system. No changes for the
user are expected. At a high level the goals are:
* Support using geometry nodes outside of the geometry nodes modifier.
* Support using the evaluator infrastructure for other purposes like field evaluation.
* Support more nodes, especially when many of them are disabled behind switch nodes.
* Support doing preprocessing on node groups.
For more details see T98492.
There are fairly detailed comments in the code, but here is a high level overview
for how it works now:
* There is a new "lazy-function" system. It is similar in spirit to the multi-function
system but with different goals. Instead of optimizing throughput for highly
parallelizable work, this system is designed to compute only the data that is actually
necessary. What data is necessary can be determined dynamically during evaluation.
Many lazy-functions can be composed in a graph to form a new lazy-function, which can
again be used in a graph etc.
* Each geometry node group is converted into a lazy-function graph prior to evaluation.
To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are
no longer inlined into their parents.
Next steps for the evaluation system is to reduce the use of threads in some situations
to avoid overhead. Many small node groups don't benefit from multi-threading at all.
This is much easier to do now because not everything has to be inlined in one huge
node tree anymore.
Differential Revision: https://developer.blender.org/D15914
The purpose of `NodeTreeRef` was to speed up various queries on a read-only
`bNodeTree`. Not that we have runtime data in nodes and sockets, we can also
store the result of some queries there. This has some benefits:
* No need for a read-only separate node tree data structure which increased
complexity.
* Makes it easier to reuse cached queries in more parts of Blender that can
benefit from it.
A downside is that we loose some type safety that we got by having different
types for input and output sockets, as well as internal and non-internal links.
This patch also refactors `DerivedNodeTree` so that it does not use
`NodeTreeRef` anymore, but uses `bNodeTree` directly instead.
To provide a convenient API (that is also close to what `NodeTreeRef` has), a
new approach is implemented: `bNodeTree`, `bNode`, `bNodeSocket` and `bNodeLink`
now have C++ methods declared in `DNA_node_types.h` which are implemented in
`BKE_node_runtime.hh`. To make this work, `makesdna` now skips c++ sections when
parsing dna header files.
No user visible changes are expected.
Differential Revision: https://developer.blender.org/D15491
While missing the break before a default that only breaks isn't
an error, it means adding new cases needs to remember to add the
break for an existing case, changing the default case will also
result in an unintended fall-through.
Also avoid `default:;` and add an explicit break.
When allocating new `CustomData` layers, often we do redundant
initialization of arrays. For example, it's common that values are
allocated, set to their default value, and then set to some other
value. This is wasteful, and it negates the benefits of optimizations
to the allocator like D15082. There are two reasons for this. The
first is array-of-structs storage that makes it annoying to initialize
values manually, and the second is confusing options in the Custom Data
API. This patch addresses the latter.
The `CustomData` "alloc type" options are rearranged. Now, besides
the options that use existing layers, there are two remaining:
* `CD_SET_DEFAULT` sets the default value.
* Usually zeroes, but for colors this is white (how it was before).
* Should be used when you add the layer but don't set all values.
* `CD_CONSTRUCT` refers to the "default construct" C++ term.
* Only necessary or defined for non-trivial types like vertex groups.
* Doesn't do anything for trivial types like `int` or `float3`.
* Should be used every other time, when all values will be set.
The attribute API's `AttributeInit` types are updated as well.
To update code, replace `CD_CALLOC` with `CD_SET_DEFAULT` and
`CD_DEFAULT` with `CD_CONSTRUCT`. This doesn't cause any functional
changes yet. Follow-up commits will change to avoid initializing
new layers where the correctness is clear.
Differential Revision: https://developer.blender.org/D15617
Using the same `GeometryComponentFieldContext` for all situations,
even when only one geometry type is supported is misleading, and mixes
too many different abstraction levels into code that could be simpler.
With the attribute API moved out of geometry components recently,
the "component" system is just getting in the way here.
This commit adds specific field contexts for geometry types: meshes,
curves, point clouds, and instances. There are also separate field input
helper classes, to help reduce boilerplate for fields that only support
specific geometry types.
Another benefit of this change is that it separates geometry components
from fields, which makes it easier to see the purpose of the two concepts,
and how they relate.
Because we want to be able to evaluate a field on just `CurvesGeometry`
rather than the full `Curves` data-block, the generic "geometry context"
had to be changed to avoid using `GeometryComponent`, since there is
no corresponding geometry component type. The resulting void pointer
is ugly, but only turns up in three places in practice. When Apple clang
supports `std::variant`, that could be used instead.
Differential Revision: https://developer.blender.org/D15519
This includes:
- new modifier names
It mostly uses `N_` because the strings are actually translated elsewhere.
The goal is simply to export them to .po files.
Most of the new translations were reported in T43295#1105335.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D15418
Currently, there are two attribute API. The first, defined in `BKE_attribute.h` is
accessible from RNA and C code. The second is implemented with `GeometryComponent`
and is only accessible in C++ code. The second is widely used, but only being
accessible through the `GeometrySet` API makes it awkward to use, and even impossible
for types that don't correspond directly to a geometry component like `CurvesGeometry`.
This patch adds a new attribute API, designed to replace the `GeometryComponent`
attribute API now, and to eventually replace or be the basis of the other one.
The basic idea is that there is an `AttributeAccessor` class that allows code to
interact with a set of attributes owned by some geometry. The accessor itself has
no ownership. `AttributeAccessor` is a simple type that can be passed around by
value. That makes it easy to return it from functions and to store it in containers.
For const-correctness, there is also a `MutableAttributeAccessor` that allows
changing individual and can add or remove attributes.
Currently, `AttributeAccessor` is composed of two pointers. The first is a pointer
to the owner of the attribute data. The second is a pointer to a struct with
function pointers, that is similar to a virtual function table. The functions
know how to access attributes on the owner.
The actual attribute access for geometries is still implemented with the `AttributeProvider`
pattern, which makes it easy to support different sources of attributes on a
geometry and simplifies dealing with built-in attributes.
There are different ways to get an attribute accessor for a geometry:
* `GeometryComponent.attributes()`
* `CurvesGeometry.attributes()`
* `bke::mesh_attributes(const Mesh &)`
* `bke::pointcloud_attributes(const PointCloud &)`
All of these also have a `_for_write` variant that returns a `MutabelAttributeAccessor`.
Differential Revision: https://developer.blender.org/D15280
Curves that are attached to a surface can now follow the surface when
it is modified using shape keys or modifiers (but not when the original
surface is deformed in edit or sculpt mode).
The surface is allowed to be changed in any way that keeps uv maps
intact. So deformation is allowed, but also some topology changes like
subdivision.
The following features are added:
* A new `Deform Curves on Surface` node, which deforms curves with
attachment information based on the surface object and uv map set
in the properties panel.
* A new `Add Rest Position` checkbox in the shape keys panel. When checked,
a new `rest_position` vector attribute is added to the mesh before shape
keys and modifiers are applied. This is necessary to support proper
deformation of the curves, but can also be used for other purposes.
* The `Add > Curve > Empty Hair` operator now sets up a simple geometry
nodes setup that deforms the hair. It also makes sure that the rest
position attribute is added to the surface.
* A new `Object (Attach Curves to Surface)` operator in the `Set Parent To`
(ctrl+P) menu, which attaches existing curves to the surface and sets the
surface object as parent.
Limitations:
* Sculpting the procedurally deformed curves will be implemented separately.
* The `Deform Curves on Surface` node is not generic and can only be used
for one specific purpose currently. We plan to generalize this more in the
future by adding support by exposing more inputs and/or by turning it into
a node group.
Differential Revision: https://developer.blender.org/D14864
This is an extension of 4669178fc3, applying the same changes to
attributes chosen in the field inputs of the geometry nodes modifier.
If a UI/internal attribute is used, the attribute name button will
have a red alert. Adding a disabled hint is currently a bit more complex.
Also hide UI attributes in attribute search for the named attribute node.
Part of D14934
`bNodeTree` has a lot of run-time embedded in it currently. Having a separately
allocated run-time struct has some benefits:
* Run-time data is not stored in files.
* Makes it easy to use c++ types as run-time data.
* More clear distinction between what data only exists at run-time and which doesn't.
This commit doesn't move all run-time data to the new struct yet, only the data where
I know for sure how it is used. The remaining data can be moved separately.
Differential Revision: https://developer.blender.org/D15033
This changes is needed to give more control to modifiers' writing
callback when defined. It will allow to implement better culling of
needless data when writing e.g. modifiers from library overrides.
Ref. T97967.
Reviewed By: brecht, JacquesLucke
Differential Revision: https://developer.blender.org/D14939
Geometry Nodes (new) icon. So far we were using the generic node-tree
icon for geometry nodes, not anymore.
The new icon is composed of 4 spheres that is a reference to the
original pebbles demo. Scattering points was also the turning point for
the project (which originally was focusing on dynamic effects), and to
this day is one of the first steps for everything procedural such as
hair.
Note that the modifier icon is still showing as white in the outliner.
The alternative is to be blue everywhere.
Patch review and feedback by Hans Goudey.
Icon creation in collaboration with Pablo Vazquez.
For properties exposed to the geometry nodes modifier, decorators didn't
work at all for colors and it only worked on the X component of vectors.
The fix is to use -1 for the RNA index of the decorator button instead
of 1, which lets the UI code figure out what to do with arrays.
Geometry node group inputs and outputs get a new property that controls
the attribute name used for that field input/output when assigning the
node group to a modifier for the first time. If the default name is assigned
to an input, the default "Use attribute name" is true .
In order to properly detect when a node group is first assigned,
the modifier now clears its properties when clearing the node group.
Ref T96707
Differential Revision: https://developer.blender.org/D14761
The new name is `Internal Dependencies`.
* Is more inline with the general goal of the panel.
* Can also show which external objects are used in the node tree in the future.
This name was choosen in the geometry nodes submodule meeting (2022-04-25).
Differential Revision: https://developer.blender.org/D14752
If the attribute already existed, but had a different domain or data type
than the user tried to write to it with (i.e. writing to `position` with
a float), then the data from field evaluation wasn't freed.
This restructures the geometry nodes modifier attribute writing process
to solve that problem and remove some of the nested if statements
that made the process confusing.
One case that still doesn't work is writing to a builtin attribute from
a different domain. If `OutputAttribute` gets that feature then that
could be supported here too.
Differential Revision: https://developer.blender.org/D14706
This adds a new subpanel to the geometry nodes modifier which is just
used to display information about used attributes.
* A new panel is used because adding this information anywhere else
clutters the ui too much imo.
* The general layout is similar to that in the tooltip. I found it to be more
trouble than it's worth to share this code.
Possible future improvements:
* Don't show the panel if there are no used named attributes.
* Add some heuristics to determine which named attributes the user does
not have to care about because they are only used in the node group
and don't affect anything else.
Differential Revision: https://developer.blender.org/D14701
The Alembic procedural was only enabled during viewport renders
originally because it did not have any caching strategy. Now that
is does, we can allow its usage in final renders.
This also removes the `dag_eval_mode` argument passing to
`ModifierTypeInfo.dependsOnTime` which was originally added to detect if
we are doing a viewport render for enabling the procedural.
Differential Revision: https://developer.blender.org/D14520
This commit moves declarations that depend on `FN_field.hh` out of
`BKE_geometry_set.hh` into `BKE_geometry_fields.hh`. This helps to
reduce the number of areas that need to depend on the functions module,
which recently came in in review of D11591.
In the future we may have a library of standard field inputs in order to
make composing algorithms easier, so it makes sense to have a header
that could contain them and some basic related utilities relating the
concepts of geometry and fields.
Reducing use of unnecessary headers may also reduce compilation time.
Differential Revision: https://developer.blender.org/D14517
Don't always create a new geometry nodes node tree when adding a
geometry nodes modifier.
This avoids files getting cluttered with empty and unused geometry node
trees that are created every time a nodes modifier is added to an
object - even if only to apply an already existing.
This is also more consistent with other modifiers that also don't
automatically create new data blocks.
The new modifier still automatically gets populated with a new node
tree when adding it via the "New" button in the header of the
geometry nodes editor.
Reviewed By: Hans Goudey, Dalai Felinto, Pablo Vazquez
Differential Revision: D14458
This commit removes the implementations of legacy nodes,
their type definitions, and related code that becomes unused.
Now that we have two releases that included the legacy nodes,
there is not much reason to include them still. Removing the
code means refactoring will be easier, and old code doesn't
have to be tested and maintained.
After this commit, the legacy nodes will be undefined in the UI,
so 3.0 or 3.1 should be used to convert files to the fields system.
The net change is 12184 lines removed!
The tooltip for legacy nodes mentioned that we would remove
them before 4.0, which was purposefully a bit vague to allow
us this flexibility. In a poll in a devtalk post showed that the
majority of people were okay with removing the nodes.
https://devtalk.blender.org/t/geometry-nodes-backward-compatibility-poll/20199
Differential Revision: https://developer.blender.org/D14353
So far it was needed to declare a new RNA struct to `RNA_access.h` manually.
Since 9b298cf3db we generate a `RNA_prototypes.h` for RNA property
declarations. Now this also includes the RNA struct declarations, so they don't
have to be added manually anymore.
Differential Revision: https://developer.blender.org/D13862
Reviewed by: brecht, campbellbarton
Limit the min and max of the IDProperty for the node group input
from 0 to infinity, and the soft min and max between 0 and 1.
Thanks to @PratikPB2123 for investigation.
For the attribute search button, the tooltip was missing
if the input socket type has attribute toggle activated.
Differential Revision: https://developer.blender.org/D14142
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
Technically, this can't be relied upon in the long term. It worked more or
less accidentally before. It was broken by a previous fix accidentally. I mainly
bring it back because rBa985f558a6eb16cd6f0 was not expected to have
this side effect.
Note, this change can result in slower performance. Writing to a vertex
groups is less efficient than using a generic attribute.
The issue was happening with a specific file where the ID management
code was not fully copying all modifiers because of the extra check
in the `BKE_object_support_modifier_type_check()`.
While it is arguable that copy-on-write should be a 1:1 copy there is
no real need to maintain the per-modifier pointer to its original.
Use its SessionUUID to perform lookup in the original datablock.
Downside of this approach is that it is a linear lookup instead of
direct pointer access, but the upside is that there is less pointers
to manage and that the file with unsupported modifiers does behave
correct without any asserts.
Differential Revision: https://developer.blender.org/D13993
