2023-08-16 00:20:26 +10:00
|
|
|
/* SPDX-FileCopyrightText: 2023 Blender Authors
|
2023-05-31 16:19:06 +02:00
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: GPL-2.0-or-later */
|
2020-12-02 13:25:25 +01:00
|
|
|
|
2022-06-05 21:05:13 +02:00
|
|
|
#include "BLI_bounds.hh"
|
Geometry Nodes: Make instances real on-demand
This commit makes the geometry output of the collection info usable.
The output is the geometry of a collection instance, but this commit
adds a utility to convert the instances to real geometry, used in the
background whenever it is needed, like copy on write.
The recursive nature of the "realize instances" code is essential,
because collection instances in the `InstancesComponent`, might have no
geometry sets of their own containing even more collection instances,
which might then contain object instances, etc.
Another consideration is that currently, every single instance contains
a reference to its data. This is inefficient since most of the time
there are many locations and only a few sets of unique data. So this
commit adds a `GeometryInstanceGroup` to support this future optimization.
The API for instances returns a vector of `GeometryInstanceGroup`.
This may be less efficient when there are many instances, but it makes
more complicated operations like point distribution that need to iterate
over input geometry multiple times much simpler.
Any code that needs to change data, like most of the attribute nodes,
can simply call `geometry_set_realize_instances(geometry_set)`,
which will move any geometry in the `InstancesComponent` to new "real"
geometry components.
Many nodes can support read-only access to instances in order to avoid
making them real, this will be addressed where needed in the near future.
Instances from the existing "dupli" system are not supported yet.
Differential Revision: https://developer.blender.org/D10327
2021-02-12 11:58:15 -06:00
|
|
|
#include "BLI_map.hh"
|
Core: introduce MemoryCounter API
We often have the situation where it would be good if we could easily estimate
the memory usage of some value (e.g. a mesh, or volume). Examples of where we
ran into this in the past:
* Undo step size.
* Caching of volume grids.
* Caching of loaded geometries for import geometry nodes.
Generally, most caching systems would benefit from the ability to know how much
memory they currently use to make better decisions about which data to free and
when. The goal of this patch is to introduce a simple general API to count the
memory usage that is independent of any specific caching system. I'm doing this
to "fix" the chicken and egg problem that caches need to know the memory usage,
but we don't really need to count the memory usage without using it for caches.
Implementing caching and memory counting at the same time make both harder than
implementing them one after another.
The main difficulty with counting memory usage is that some memory may be shared
using implicit sharing. We want to avoid double counting such memory. How
exactly shared memory is treated depends a bit on the use case, so no specific
assumptions are made about that in the API. The gathered memory usage is not
expected to be exact. It's expected to be a decent approximation. It's neither a
lower nor an upper bound unless specified by some specific type. Cache systems
generally build on top of heuristics to decide when to free what anyway.
There are two sides to this API:
1. Get the amount of memory used by one or more values. This side is used by
caching systems and/or systems that want to present the used memory to the
user.
2. Tell the caller how much memory is used. This side is used by all kinds of
types that can report their memory usage such as meshes.
```cpp
/* Get how much memory is used by two meshes together. */
MemoryCounter memory;
mesh_a->count_memory(memory);
mesh_b->count_memory(memory);
int64_t bytes_used = memory.counted_bytes();
/* Tell the caller how much memory is used. */
void Mesh::count_memory(blender::MemoryCounter &memory) const
{
memory.add_shared(this->runtime->face_offsets_sharing_info,
this->face_offsets().size_in_bytes());
/* Forward memory counting to lower level types. This should be fairly common. */
CustomData_count_memory(this->vert_data, this->verts_num, memory);
}
void CustomData_count_memory(const CustomData &data,
const int totelem,
blender::MemoryCounter &memory)
{
for (const CustomDataLayer &layer : Span{data.layers, data.totlayer}) {
memory.add_shared(layer.sharing_info, [&](blender::MemoryCounter &shared_memory) {
/* Not quite correct for all types, but this is only a rough approximation anyway. */
const int64_t elem_size = CustomData_get_elem_size(&layer);
shared_memory.add(totelem * elem_size);
});
}
}
```
Pull Request: https://projects.blender.org/blender/blender/pulls/126295
2024-08-15 10:54:21 +02:00
|
|
|
#include "BLI_memory_counter.hh"
|
2021-09-28 10:17:00 +02:00
|
|
|
#include "BLI_task.hh"
|
Geometry Nodes: Make instances real on-demand
This commit makes the geometry output of the collection info usable.
The output is the geometry of a collection instance, but this commit
adds a utility to convert the instances to real geometry, used in the
background whenever it is needed, like copy on write.
The recursive nature of the "realize instances" code is essential,
because collection instances in the `InstancesComponent`, might have no
geometry sets of their own containing even more collection instances,
which might then contain object instances, etc.
Another consideration is that currently, every single instance contains
a reference to its data. This is inefficient since most of the time
there are many locations and only a few sets of unique data. So this
commit adds a `GeometryInstanceGroup` to support this future optimization.
The API for instances returns a vector of `GeometryInstanceGroup`.
This may be less efficient when there are many instances, but it makes
more complicated operations like point distribution that need to iterate
over input geometry multiple times much simpler.
Any code that needs to change data, like most of the attribute nodes,
can simply call `geometry_set_realize_instances(geometry_set)`,
which will move any geometry in the `InstancesComponent` to new "real"
geometry components.
Many nodes can support read-only access to instances in order to avoid
making them real, this will be addressed where needed in the near future.
Instances from the existing "dupli" system are not supported yet.
Differential Revision: https://developer.blender.org/D10327
2021-02-12 11:58:15 -06:00
|
|
|
|
2024-02-09 18:59:42 +01:00
|
|
|
#include "BLT_translation.hh"
|
2022-01-10 16:41:05 -06:00
|
|
|
|
2023-12-20 13:25:08 -05:00
|
|
|
#include "BKE_attribute.hh"
|
2022-02-28 10:46:34 -05:00
|
|
|
#include "BKE_curves.hh"
|
2020-12-02 13:25:25 +01:00
|
|
|
#include "BKE_geometry_set.hh"
|
2023-06-15 22:18:28 +02:00
|
|
|
#include "BKE_geometry_set_instances.hh"
|
2023-08-02 17:36:38 +02:00
|
|
|
#include "BKE_grease_pencil.hh"
|
2022-10-17 11:39:40 +02:00
|
|
|
#include "BKE_instances.hh"
|
2024-01-15 12:44:04 -05:00
|
|
|
#include "BKE_lib_id.hh"
|
2023-03-12 22:29:15 +01:00
|
|
|
#include "BKE_mesh.hh"
|
2023-08-02 22:14:18 +02:00
|
|
|
#include "BKE_mesh_wrapper.hh"
|
2023-11-14 09:30:40 +01:00
|
|
|
#include "BKE_modifier.hh"
|
2023-11-15 18:46:07 +01:00
|
|
|
#include "BKE_object_types.hh"
|
2024-01-11 10:54:47 +01:00
|
|
|
#include "BKE_pointcloud.hh"
|
2023-11-16 11:41:55 +01:00
|
|
|
#include "BKE_volume.hh"
|
2020-12-02 13:25:25 +01:00
|
|
|
|
Geometry Nodes: Make instances real on-demand
This commit makes the geometry output of the collection info usable.
The output is the geometry of a collection instance, but this commit
adds a utility to convert the instances to real geometry, used in the
background whenever it is needed, like copy on write.
The recursive nature of the "realize instances" code is essential,
because collection instances in the `InstancesComponent`, might have no
geometry sets of their own containing even more collection instances,
which might then contain object instances, etc.
Another consideration is that currently, every single instance contains
a reference to its data. This is inefficient since most of the time
there are many locations and only a few sets of unique data. So this
commit adds a `GeometryInstanceGroup` to support this future optimization.
The API for instances returns a vector of `GeometryInstanceGroup`.
This may be less efficient when there are many instances, but it makes
more complicated operations like point distribution that need to iterate
over input geometry multiple times much simpler.
Any code that needs to change data, like most of the attribute nodes,
can simply call `geometry_set_realize_instances(geometry_set)`,
which will move any geometry in the `InstancesComponent` to new "real"
geometry components.
Many nodes can support read-only access to instances in order to avoid
making them real, this will be addressed where needed in the near future.
Instances from the existing "dupli" system are not supported yet.
Differential Revision: https://developer.blender.org/D10327
2021-02-12 11:58:15 -06:00
|
|
|
#include "DNA_collection_types.h"
|
2020-12-02 13:25:25 +01:00
|
|
|
#include "DNA_object_types.h"
|
2022-09-07 10:43:46 +02:00
|
|
|
#include "DNA_pointcloud_types.h"
|
2020-12-02 13:25:25 +01:00
|
|
|
|
2021-02-12 17:41:28 +01:00
|
|
|
#include "BLI_rand.hh"
|
|
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
|
2023-07-09 21:40:17 +10:00
|
|
|
namespace blender::bke {
|
|
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
/** \name Geometry Component
|
|
|
|
|
* \{ */
|
|
|
|
|
|
2023-06-15 22:18:28 +02:00
|
|
|
GeometryComponent::GeometryComponent(Type type) : type_(type) {}
|
2020-12-02 13:25:25 +01:00
|
|
|
|
2023-06-15 22:18:28 +02:00
|
|
|
GeometryComponentPtr GeometryComponent::create(Type component_type)
|
2020-12-02 13:25:25 +01:00
|
|
|
{
|
|
|
|
|
switch (component_type) {
|
2023-06-15 22:18:28 +02:00
|
|
|
case Type::Mesh:
|
2023-11-27 15:53:29 +01:00
|
|
|
return GeometryComponentPtr(new MeshComponent());
|
2023-06-15 22:18:28 +02:00
|
|
|
case Type::PointCloud:
|
2023-11-27 15:53:29 +01:00
|
|
|
return GeometryComponentPtr(new PointCloudComponent());
|
2023-06-15 22:18:28 +02:00
|
|
|
case Type::Instance:
|
2023-11-27 15:53:29 +01:00
|
|
|
return GeometryComponentPtr(new InstancesComponent());
|
2023-06-15 22:18:28 +02:00
|
|
|
case Type::Volume:
|
2023-11-27 15:53:29 +01:00
|
|
|
return GeometryComponentPtr(new VolumeComponent());
|
2023-06-15 22:18:28 +02:00
|
|
|
case Type::Curve:
|
2023-11-27 15:53:29 +01:00
|
|
|
return GeometryComponentPtr(new CurveComponent());
|
2023-06-15 22:18:28 +02:00
|
|
|
case Type::Edit:
|
2023-11-27 15:53:29 +01:00
|
|
|
return GeometryComponentPtr(new GeometryComponentEditData());
|
2023-07-26 13:59:37 +02:00
|
|
|
case Type::GreasePencil:
|
2023-11-27 15:53:29 +01:00
|
|
|
return GeometryComponentPtr(new GreasePencilComponent());
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
2021-03-23 16:49:47 +01:00
|
|
|
BLI_assert_unreachable();
|
BLI: support weak users and version in implicit sharing info
The main goal of these changes is to support checking if some data has
been changed over time. This is used by the WIP simulation nodes during
baking to detect which attributes have to be stored in every frame because
they have changed.
By using a combination of a weak user count and a version counter, it is
possible to detect that an attribute (or any data controlled by implicit
sharing) has not been changed with O(1) memory and time. It's still
possible that the data has been changed multiple times and is the same
in the end and beginning of course. That wouldn't be detected using this
mechanism.
The `ImplicitSharingInfo` struct has a new weak user count. A weak
reference is one that does not keep the referenced data alive, but makes sure
that the `ImplicitSharingInfo` itself is not deleted. If some piece of
data has one strong and multiple weak users, it is still mutable. If the
strong user count goes down to zero, the referenced data is freed.
Remaining weak users can check for this condition using `is_expired`.
This is a bit similar to `std::weak_ptr` but there is an important difference:
a weak user can not become a strong user while one can create a `shared_ptr`
from a `weak_ptr`. This restriction is necessary, because some code might
be changing the referenced data assuming that it is the only owner. If
another thread suddenly adds a new owner, the data would be shared again
and the first thread would not have been allowed to modify the data in
the first place.
There is also a new integer version counter in `ImplicitSharingInfo`.
It is incremented whenever some code wants to modify the referenced data.
Obviously, this can only be done when the data is not shared because then
it would be immutable. By comparing an old and new version number of the
same sharing info, one can check if the data has been modified. One has
to keep a weak reference to the sharing info together with the old version
number to ensure that the new sharing info is still the same as the old one.
Without this, it can happen that the sharing info was freed and a new
one was allocated at the same pointer address. Using a strong reference
for this purpose does not work, because then the data would never be
modified because it's shared.
2023-04-28 12:03:42 +02:00
|
|
|
return {};
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
|
|
2023-12-20 13:13:16 -05:00
|
|
|
int GeometryComponent::attribute_domain_size(const AttrDomain domain) const
|
Geometry Nodes: new geometry attribute API
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
2022-07-08 16:16:56 +02:00
|
|
|
{
|
|
|
|
|
if (this->is_empty()) {
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2023-06-15 22:18:28 +02:00
|
|
|
const std::optional<AttributeAccessor> attributes = this->attributes();
|
Geometry Nodes: new geometry attribute API
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
2022-07-08 16:16:56 +02:00
|
|
|
if (attributes.has_value()) {
|
|
|
|
|
return attributes->domain_size(domain);
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2023-06-15 22:18:28 +02:00
|
|
|
std::optional<AttributeAccessor> GeometryComponent::attributes() const
|
Geometry Nodes: new geometry attribute API
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
2022-07-08 16:16:56 +02:00
|
|
|
{
|
|
|
|
|
return std::nullopt;
|
|
|
|
|
};
|
2023-06-15 22:18:28 +02:00
|
|
|
std::optional<MutableAttributeAccessor> GeometryComponent::attributes_for_write()
|
Geometry Nodes: new geometry attribute API
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
2022-07-08 16:16:56 +02:00
|
|
|
{
|
|
|
|
|
return std::nullopt;
|
|
|
|
|
}
|
|
|
|
|
|
Core: introduce MemoryCounter API
We often have the situation where it would be good if we could easily estimate
the memory usage of some value (e.g. a mesh, or volume). Examples of where we
ran into this in the past:
* Undo step size.
* Caching of volume grids.
* Caching of loaded geometries for import geometry nodes.
Generally, most caching systems would benefit from the ability to know how much
memory they currently use to make better decisions about which data to free and
when. The goal of this patch is to introduce a simple general API to count the
memory usage that is independent of any specific caching system. I'm doing this
to "fix" the chicken and egg problem that caches need to know the memory usage,
but we don't really need to count the memory usage without using it for caches.
Implementing caching and memory counting at the same time make both harder than
implementing them one after another.
The main difficulty with counting memory usage is that some memory may be shared
using implicit sharing. We want to avoid double counting such memory. How
exactly shared memory is treated depends a bit on the use case, so no specific
assumptions are made about that in the API. The gathered memory usage is not
expected to be exact. It's expected to be a decent approximation. It's neither a
lower nor an upper bound unless specified by some specific type. Cache systems
generally build on top of heuristics to decide when to free what anyway.
There are two sides to this API:
1. Get the amount of memory used by one or more values. This side is used by
caching systems and/or systems that want to present the used memory to the
user.
2. Tell the caller how much memory is used. This side is used by all kinds of
types that can report their memory usage such as meshes.
```cpp
/* Get how much memory is used by two meshes together. */
MemoryCounter memory;
mesh_a->count_memory(memory);
mesh_b->count_memory(memory);
int64_t bytes_used = memory.counted_bytes();
/* Tell the caller how much memory is used. */
void Mesh::count_memory(blender::MemoryCounter &memory) const
{
memory.add_shared(this->runtime->face_offsets_sharing_info,
this->face_offsets().size_in_bytes());
/* Forward memory counting to lower level types. This should be fairly common. */
CustomData_count_memory(this->vert_data, this->verts_num, memory);
}
void CustomData_count_memory(const CustomData &data,
const int totelem,
blender::MemoryCounter &memory)
{
for (const CustomDataLayer &layer : Span{data.layers, data.totlayer}) {
memory.add_shared(layer.sharing_info, [&](blender::MemoryCounter &shared_memory) {
/* Not quite correct for all types, but this is only a rough approximation anyway. */
const int64_t elem_size = CustomData_get_elem_size(&layer);
shared_memory.add(totelem * elem_size);
});
}
}
```
Pull Request: https://projects.blender.org/blender/blender/pulls/126295
2024-08-15 10:54:21 +02:00
|
|
|
void GeometryComponent::count_memory(MemoryCounter & /*memory*/) const {}
|
|
|
|
|
|
2023-06-15 22:18:28 +02:00
|
|
|
GeometryComponent::Type GeometryComponent::type() const
|
2020-12-02 13:25:25 +01:00
|
|
|
{
|
|
|
|
|
return type_;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool GeometryComponent::is_empty() const
|
|
|
|
|
{
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2023-03-28 13:57:51 +02:00
|
|
|
void GeometryComponent::delete_self()
|
|
|
|
|
{
|
|
|
|
|
delete this;
|
|
|
|
|
}
|
|
|
|
|
|
BLI: support weak users and version in implicit sharing info
The main goal of these changes is to support checking if some data has
been changed over time. This is used by the WIP simulation nodes during
baking to detect which attributes have to be stored in every frame because
they have changed.
By using a combination of a weak user count and a version counter, it is
possible to detect that an attribute (or any data controlled by implicit
sharing) has not been changed with O(1) memory and time. It's still
possible that the data has been changed multiple times and is the same
in the end and beginning of course. That wouldn't be detected using this
mechanism.
The `ImplicitSharingInfo` struct has a new weak user count. A weak
reference is one that does not keep the referenced data alive, but makes sure
that the `ImplicitSharingInfo` itself is not deleted. If some piece of
data has one strong and multiple weak users, it is still mutable. If the
strong user count goes down to zero, the referenced data is freed.
Remaining weak users can check for this condition using `is_expired`.
This is a bit similar to `std::weak_ptr` but there is an important difference:
a weak user can not become a strong user while one can create a `shared_ptr`
from a `weak_ptr`. This restriction is necessary, because some code might
be changing the referenced data assuming that it is the only owner. If
another thread suddenly adds a new owner, the data would be shared again
and the first thread would not have been allowed to modify the data in
the first place.
There is also a new integer version counter in `ImplicitSharingInfo`.
It is incremented whenever some code wants to modify the referenced data.
Obviously, this can only be done when the data is not shared because then
it would be immutable. By comparing an old and new version number of the
same sharing info, one can check if the data has been modified. One has
to keep a weak reference to the sharing info together with the old version
number to ensure that the new sharing info is still the same as the old one.
Without this, it can happen that the sharing info was freed and a new
one was allocated at the same pointer address. Using a strong reference
for this purpose does not work, because then the data would never be
modified because it's shared.
2023-04-28 12:03:42 +02:00
|
|
|
void GeometryComponent::delete_data_only()
|
|
|
|
|
{
|
|
|
|
|
this->clear();
|
|
|
|
|
}
|
|
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
/** \} */
|
|
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
/** \name Geometry Set
|
|
|
|
|
* \{ */
|
|
|
|
|
|
2021-10-03 16:58:33 +02:00
|
|
|
GeometrySet::GeometrySet() = default;
|
|
|
|
|
GeometrySet::GeometrySet(const GeometrySet &other) = default;
|
|
|
|
|
GeometrySet::GeometrySet(GeometrySet &&other) = default;
|
|
|
|
|
GeometrySet::~GeometrySet() = default;
|
|
|
|
|
GeometrySet &GeometrySet::operator=(const GeometrySet &other) = default;
|
|
|
|
|
GeometrySet &GeometrySet::operator=(GeometrySet &&other) = default;
|
|
|
|
|
|
2023-06-15 22:18:28 +02:00
|
|
|
GeometryComponent &GeometrySet::get_component_for_write(GeometryComponent::Type component_type)
|
2020-12-02 13:25:25 +01:00
|
|
|
{
|
2023-06-15 22:18:28 +02:00
|
|
|
GeometryComponentPtr &component_ptr = components_[size_t(component_type)];
|
2021-12-05 15:10:11 +01:00
|
|
|
if (!component_ptr) {
|
|
|
|
|
/* If the component did not exist before, create a new one. */
|
|
|
|
|
component_ptr = GeometryComponent::create(component_type);
|
|
|
|
|
}
|
2023-12-01 11:19:39 +01:00
|
|
|
else if (component_ptr->is_mutable()) {
|
2021-12-05 15:10:11 +01:00
|
|
|
/* If the referenced component is already mutable, return it directly. */
|
BLI: support weak users and version in implicit sharing info
The main goal of these changes is to support checking if some data has
been changed over time. This is used by the WIP simulation nodes during
baking to detect which attributes have to be stored in every frame because
they have changed.
By using a combination of a weak user count and a version counter, it is
possible to detect that an attribute (or any data controlled by implicit
sharing) has not been changed with O(1) memory and time. It's still
possible that the data has been changed multiple times and is the same
in the end and beginning of course. That wouldn't be detected using this
mechanism.
The `ImplicitSharingInfo` struct has a new weak user count. A weak
reference is one that does not keep the referenced data alive, but makes sure
that the `ImplicitSharingInfo` itself is not deleted. If some piece of
data has one strong and multiple weak users, it is still mutable. If the
strong user count goes down to zero, the referenced data is freed.
Remaining weak users can check for this condition using `is_expired`.
This is a bit similar to `std::weak_ptr` but there is an important difference:
a weak user can not become a strong user while one can create a `shared_ptr`
from a `weak_ptr`. This restriction is necessary, because some code might
be changing the referenced data assuming that it is the only owner. If
another thread suddenly adds a new owner, the data would be shared again
and the first thread would not have been allowed to modify the data in
the first place.
There is also a new integer version counter in `ImplicitSharingInfo`.
It is incremented whenever some code wants to modify the referenced data.
Obviously, this can only be done when the data is not shared because then
it would be immutable. By comparing an old and new version number of the
same sharing info, one can check if the data has been modified. One has
to keep a weak reference to the sharing info together with the old version
number to ensure that the new sharing info is still the same as the old one.
Without this, it can happen that the sharing info was freed and a new
one was allocated at the same pointer address. Using a strong reference
for this purpose does not work, because then the data would never be
modified because it's shared.
2023-04-28 12:03:42 +02:00
|
|
|
component_ptr->tag_ensured_mutable();
|
2021-12-05 15:10:11 +01:00
|
|
|
}
|
2023-12-01 11:19:39 +01:00
|
|
|
else {
|
|
|
|
|
/* If the referenced component is shared, make a copy. The copy is not shared and is
|
|
|
|
|
* therefore mutable. */
|
2023-12-01 11:23:00 +01:00
|
|
|
component_ptr = component_ptr->copy();
|
2023-12-01 11:19:39 +01:00
|
|
|
}
|
|
|
|
|
return const_cast<GeometryComponent &>(*component_ptr);
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
|
|
2023-06-15 22:18:28 +02:00
|
|
|
GeometryComponent *GeometrySet::get_component_ptr(GeometryComponent::Type type)
|
2021-10-14 12:43:36 -05:00
|
|
|
{
|
2021-10-15 13:39:11 +02:00
|
|
|
if (this->has(type)) {
|
|
|
|
|
return &this->get_component_for_write(type);
|
|
|
|
|
}
|
|
|
|
|
return nullptr;
|
2021-10-14 12:43:36 -05:00
|
|
|
}
|
|
|
|
|
|
2023-08-03 17:09:18 +02:00
|
|
|
const GeometryComponent *GeometrySet::get_component(GeometryComponent::Type component_type) const
|
2020-12-02 13:25:25 +01:00
|
|
|
{
|
2023-06-15 22:18:28 +02:00
|
|
|
return components_[size_t(component_type)].get();
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
|
|
2023-06-15 22:18:28 +02:00
|
|
|
bool GeometrySet::has(const GeometryComponent::Type component_type) const
|
2020-12-02 13:25:25 +01:00
|
|
|
{
|
2023-06-15 22:18:28 +02:00
|
|
|
const GeometryComponentPtr &component = components_[size_t(component_type)];
|
2022-11-22 15:40:42 -06:00
|
|
|
return component.has_value() && !component->is_empty();
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
|
|
2023-06-15 22:18:28 +02:00
|
|
|
void GeometrySet::remove(const GeometryComponent::Type component_type)
|
2020-12-02 13:25:25 +01:00
|
|
|
{
|
2023-06-15 22:18:28 +02:00
|
|
|
components_[size_t(component_type)].reset();
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
|
|
2023-06-15 22:18:28 +02:00
|
|
|
void GeometrySet::keep_only(const Span<GeometryComponent::Type> component_types)
|
2021-09-28 15:52:04 +02:00
|
|
|
{
|
2021-12-05 15:10:11 +01:00
|
|
|
for (GeometryComponentPtr &component_ptr : components_) {
|
|
|
|
|
if (component_ptr) {
|
|
|
|
|
if (!component_types.contains(component_ptr->type())) {
|
|
|
|
|
component_ptr.reset();
|
|
|
|
|
}
|
2021-09-28 15:52:04 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-06-15 22:18:28 +02:00
|
|
|
void GeometrySet::keep_only_during_modify(const Span<GeometryComponent::Type> component_types)
|
2022-07-22 15:39:41 +02:00
|
|
|
{
|
2023-06-15 22:18:28 +02:00
|
|
|
Vector<GeometryComponent::Type> extended_types = component_types;
|
|
|
|
|
extended_types.append_non_duplicates(GeometryComponent::Type::Instance);
|
|
|
|
|
extended_types.append_non_duplicates(GeometryComponent::Type::Edit);
|
2022-07-22 15:39:41 +02:00
|
|
|
this->keep_only(extended_types);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void GeometrySet::remove_geometry_during_modify()
|
|
|
|
|
{
|
|
|
|
|
this->keep_only_during_modify({});
|
|
|
|
|
}
|
|
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
void GeometrySet::add(const GeometryComponent &component)
|
|
|
|
|
{
|
2023-06-15 22:18:28 +02:00
|
|
|
BLI_assert(!components_[size_t(component.type())]);
|
2023-03-28 13:57:51 +02:00
|
|
|
component.add_user();
|
2023-11-27 15:53:29 +01:00
|
|
|
components_[size_t(component.type())] = GeometryComponentPtr(
|
|
|
|
|
const_cast<GeometryComponent *>(&component));
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
|
|
2023-08-03 17:09:18 +02:00
|
|
|
Vector<const GeometryComponent *> GeometrySet::get_components() const
|
2021-02-19 12:29:37 +01:00
|
|
|
{
|
|
|
|
|
Vector<const GeometryComponent *> components;
|
2021-12-05 15:10:11 +01:00
|
|
|
for (const GeometryComponentPtr &component_ptr : components_) {
|
|
|
|
|
if (component_ptr) {
|
|
|
|
|
components.append(component_ptr.get());
|
|
|
|
|
}
|
2021-02-19 12:29:37 +01:00
|
|
|
}
|
|
|
|
|
return components;
|
|
|
|
|
}
|
|
|
|
|
|
2023-06-16 08:08:18 -04:00
|
|
|
std::optional<Bounds<float3>> GeometrySet::compute_boundbox_without_instances() const
|
2020-12-02 13:25:25 +01:00
|
|
|
{
|
2023-06-16 08:08:18 -04:00
|
|
|
std::optional<Bounds<float3>> bounds;
|
2023-08-03 17:09:18 +02:00
|
|
|
if (const PointCloud *pointcloud = this->get_pointcloud()) {
|
2023-06-16 08:08:18 -04:00
|
|
|
bounds = bounds::merge(bounds, pointcloud->bounds_min_max());
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
2023-08-03 17:09:18 +02:00
|
|
|
if (const Mesh *mesh = this->get_mesh()) {
|
2023-11-19 18:36:19 -05:00
|
|
|
bounds = bounds::merge(bounds, mesh->bounds_min_max());
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
2023-08-03 17:09:18 +02:00
|
|
|
if (const Volume *volume = this->get_volume()) {
|
2023-11-27 16:14:49 +01:00
|
|
|
bounds = bounds::merge(bounds, BKE_volume_min_max(volume));
|
2021-04-08 14:32:41 -05:00
|
|
|
}
|
2023-08-03 17:09:18 +02:00
|
|
|
if (const Curves *curves_id = this->get_curves()) {
|
2023-06-16 08:08:18 -04:00
|
|
|
bounds = bounds::merge(bounds, curves_id->geometry.wrap().bounds_min_max());
|
Geometry Nodes: Initial basic curve data support
This patch adds initial curve support to geometry nodes. Currently
there is only one node available, the "Curve to Mesh" node, T87428.
However, the aim of the changes here is larger than just supporting
curve data in nodes-- it also uses the opportunity to add better spline
data structures, intended to replace the existing curve evaluation code.
The curve code in Blender is quite old, and it's generally regarded as
some of the messiest, hardest-to-understand code as well. The classes
in `BKE_spline.hh` aim to be faster, more extensible, and much more
easily understandable. Further explanation can be found in comments in
that file.
Initial builtin spline attributes are supported-- reading and writing
from the `cyclic` and `resolution` attributes works with any of the
attribute nodes. Also, only Z-up normal calculation is implemented
at the moment, and tilts do not apply yet.
**Limitations**
- For now, you must bring curves into the node tree with an "Object
Info" node. Changes to the curve modifier stack will come later.
- Converting to a mesh is necessary to visualize the curve data.
Further progress can be tracked in: T87245
Higher level design document: https://wiki.blender.org/wiki/Modules/Physics_Nodes/Projects/EverythingNodes/CurveNodes
Differential Revision: https://developer.blender.org/D11091
2021-05-03 12:29:17 -05:00
|
|
|
}
|
2023-08-03 17:09:18 +02:00
|
|
|
if (const GreasePencil *grease_pencil = this->get_grease_pencil()) {
|
2023-11-27 15:06:24 +01:00
|
|
|
bounds = bounds::merge(bounds, grease_pencil->bounds_min_max_eval());
|
2023-08-02 17:36:38 +02:00
|
|
|
}
|
2023-06-16 08:08:18 -04:00
|
|
|
return bounds;
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
std::ostream &operator<<(std::ostream &stream, const GeometrySet &geometry_set)
|
|
|
|
|
{
|
2022-09-07 10:43:46 +02:00
|
|
|
Vector<std::string> parts;
|
2023-08-03 17:09:18 +02:00
|
|
|
if (const Mesh *mesh = geometry_set.get_mesh()) {
|
2023-12-20 02:21:48 +01:00
|
|
|
parts.append(std::to_string(mesh->verts_num) + " verts");
|
|
|
|
|
parts.append(std::to_string(mesh->edges_num) + " edges");
|
2023-07-24 22:06:55 +02:00
|
|
|
parts.append(std::to_string(mesh->faces_num) + " faces");
|
2023-12-20 02:21:48 +01:00
|
|
|
parts.append(std::to_string(mesh->corners_num) + " corners");
|
2022-09-07 10:43:46 +02:00
|
|
|
}
|
2023-08-03 17:09:18 +02:00
|
|
|
if (const Curves *curves = geometry_set.get_curves()) {
|
2022-09-07 10:43:46 +02:00
|
|
|
parts.append(std::to_string(curves->geometry.point_num) + " control points");
|
|
|
|
|
parts.append(std::to_string(curves->geometry.curve_num) + " curves");
|
|
|
|
|
}
|
2023-10-10 16:49:30 +02:00
|
|
|
if (const GreasePencil *grease_pencil = geometry_set.get_grease_pencil()) {
|
2024-10-15 13:00:47 +02:00
|
|
|
parts.append(std::to_string(grease_pencil->layers().size()) + " Grease Pencil layers");
|
2023-10-10 16:49:30 +02:00
|
|
|
}
|
2023-08-03 17:09:18 +02:00
|
|
|
if (const PointCloud *point_cloud = geometry_set.get_pointcloud()) {
|
2022-09-07 10:43:46 +02:00
|
|
|
parts.append(std::to_string(point_cloud->totpoint) + " points");
|
|
|
|
|
}
|
2023-08-03 17:09:18 +02:00
|
|
|
if (const Volume *volume = geometry_set.get_volume()) {
|
2022-09-07 10:43:46 +02:00
|
|
|
parts.append(std::to_string(BKE_volume_num_grids(volume)) + " volume grids");
|
|
|
|
|
}
|
|
|
|
|
if (geometry_set.has_instances()) {
|
2023-08-03 17:09:18 +02:00
|
|
|
parts.append(std::to_string(geometry_set.get_instances()->instances_num()) + " instances");
|
2022-09-07 10:43:46 +02:00
|
|
|
}
|
2023-08-03 17:09:18 +02:00
|
|
|
if (geometry_set.get_curve_edit_hints()) {
|
2022-09-07 10:43:46 +02:00
|
|
|
parts.append("curve edit hints");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
stream << "<GeometrySet: ";
|
|
|
|
|
for (const int i : parts.index_range()) {
|
|
|
|
|
stream << parts[i];
|
|
|
|
|
if (i < parts.size() - 1) {
|
|
|
|
|
stream << ", ";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
stream << ">";
|
2020-12-02 13:25:25 +01:00
|
|
|
return stream;
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-30 12:34:05 +02:00
|
|
|
void GeometrySet::clear()
|
|
|
|
|
{
|
2021-12-05 15:10:11 +01:00
|
|
|
for (GeometryComponentPtr &component_ptr : components_) {
|
|
|
|
|
component_ptr.reset();
|
|
|
|
|
}
|
2021-03-30 12:34:05 +02:00
|
|
|
}
|
|
|
|
|
|
2021-04-08 17:35:06 +02:00
|
|
|
void GeometrySet::ensure_owns_direct_data()
|
|
|
|
|
{
|
2021-12-05 15:10:11 +01:00
|
|
|
for (GeometryComponentPtr &component_ptr : components_) {
|
|
|
|
|
if (!component_ptr) {
|
|
|
|
|
continue;
|
2021-04-08 17:35:06 +02:00
|
|
|
}
|
2021-12-05 15:10:11 +01:00
|
|
|
if (component_ptr->owns_direct_data()) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
GeometryComponent &component_for_write = this->get_component_for_write(component_ptr->type());
|
|
|
|
|
component_for_write.ensure_owns_direct_data();
|
2021-04-08 17:35:06 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Geometry Nodes: add simulation support
This adds support for building simulations with geometry nodes. A new
`Simulation Input` and `Simulation Output` node allow maintaining a
simulation state across multiple frames. Together these two nodes form
a `simulation zone` which contains all the nodes that update the simulation
state from one frame to the next.
A new simulation zone can be added via the menu
(`Simulation > Simulation Zone`) or with the node add search.
The simulation state contains a geometry by default. However, it is possible
to add multiple geometry sockets as well as other socket types. Currently,
field inputs are evaluated and stored for the preceding geometry socket in
the order that the sockets are shown. Simulation state items can be added
by linking one of the empty sockets to something else. In the sidebar, there
is a new panel that allows adding, removing and reordering these sockets.
The simulation nodes behave as follows:
* On the first frame, the inputs of the `Simulation Input` node are evaluated
to initialize the simulation state. In later frames these sockets are not
evaluated anymore. The `Delta Time` at the first frame is zero, but the
simulation zone is still evaluated.
* On every next frame, the `Simulation Input` node outputs the simulation
state of the previous frame. Nodes in the simulation zone can edit that
data in arbitrary ways, also taking into account the `Delta Time`. The new
simulation state has to be passed to the `Simulation Output` node where it
is cached and forwarded.
* On a frame that is already cached or baked, the nodes in the simulation
zone are not evaluated, because the `Simulation Output` node can return
the previously cached data directly.
It is not allowed to connect sockets from inside the simulation zone to the
outside without going through the `Simulation Output` node. This is a necessary
restriction to make caching and sub-frame interpolation work. Links can go into
the simulation zone without problems though.
Anonymous attributes are not propagated by the simulation nodes unless they
are explicitly stored in the simulation state. This is unfortunate, but
currently there is no practical and reliable alternative. The core problem
is detecting which anonymous attributes will be required for the simulation
and afterwards. While we can detect this for the current evaluation, we can't
look into the future in time to see what data will be necessary. We intend to
make it easier to explicitly pass data through a simulation in the future,
even if the simulation is in a nested node group.
There is a new `Simulation Nodes` panel in the physics tab in the properties
editor. It allows baking all simulation zones on the selected objects. The
baking options are intentially kept at a minimum for this MVP. More features
for simulation baking as well as baking in general can be expected to be added
separately.
All baked data is stored on disk in a folder next to the .blend file. #106937
describes how baking is implemented in more detail. Volumes can not be baked
yet and materials are lost during baking for now. Packing the baked data into
the .blend file is not yet supported.
The timeline indicates which frames are currently cached, baked or cached but
invalidated by user-changes.
Simulation input and output nodes are internally linked together by their
`bNode.identifier` which stays the same even if the node name changes. They
are generally added and removed together. However, there are still cases where
"dangling" simulation nodes can be created currently. Those generally don't
cause harm, but would be nice to avoid this in more cases in the future.
Co-authored-by: Hans Goudey <h.goudey@me.com>
Co-authored-by: Lukas Tönne <lukas@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/104924
2023-05-03 13:18:51 +02:00
|
|
|
void GeometrySet::ensure_owns_all_data()
|
|
|
|
|
{
|
|
|
|
|
if (Instances *instances = this->get_instances_for_write()) {
|
|
|
|
|
instances->ensure_geometry_instances();
|
|
|
|
|
}
|
|
|
|
|
this->ensure_owns_direct_data();
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-06 18:22:24 +02:00
|
|
|
bool GeometrySet::owns_direct_data() const
|
|
|
|
|
{
|
2021-12-05 15:10:11 +01:00
|
|
|
for (const GeometryComponentPtr &component_ptr : components_) {
|
|
|
|
|
if (component_ptr) {
|
|
|
|
|
if (!component_ptr->owns_direct_data()) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2021-09-06 18:22:24 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-03 17:09:18 +02:00
|
|
|
const Mesh *GeometrySet::get_mesh() const
|
2020-12-02 13:25:25 +01:00
|
|
|
{
|
2023-08-03 17:09:18 +02:00
|
|
|
const MeshComponent *component = this->get_component<MeshComponent>();
|
|
|
|
|
return (component == nullptr) ? nullptr : component->get();
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool GeometrySet::has_mesh() const
|
|
|
|
|
{
|
2023-08-03 17:09:18 +02:00
|
|
|
const MeshComponent *component = this->get_component<MeshComponent>();
|
2020-12-02 13:25:25 +01:00
|
|
|
return component != nullptr && component->has_mesh();
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-03 17:09:18 +02:00
|
|
|
const PointCloud *GeometrySet::get_pointcloud() const
|
2020-12-02 13:25:25 +01:00
|
|
|
{
|
2023-08-03 17:09:18 +02:00
|
|
|
const PointCloudComponent *component = this->get_component<PointCloudComponent>();
|
|
|
|
|
return (component == nullptr) ? nullptr : component->get();
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
|
|
2023-08-03 17:09:18 +02:00
|
|
|
const Volume *GeometrySet::get_volume() const
|
2021-01-21 10:32:42 +01:00
|
|
|
{
|
2023-08-03 17:09:18 +02:00
|
|
|
const VolumeComponent *component = this->get_component<VolumeComponent>();
|
|
|
|
|
return (component == nullptr) ? nullptr : component->get();
|
2021-01-21 10:32:42 +01:00
|
|
|
}
|
|
|
|
|
|
2023-08-03 17:09:18 +02:00
|
|
|
const Curves *GeometrySet::get_curves() const
|
Geometry Nodes: Initial basic curve data support
This patch adds initial curve support to geometry nodes. Currently
there is only one node available, the "Curve to Mesh" node, T87428.
However, the aim of the changes here is larger than just supporting
curve data in nodes-- it also uses the opportunity to add better spline
data structures, intended to replace the existing curve evaluation code.
The curve code in Blender is quite old, and it's generally regarded as
some of the messiest, hardest-to-understand code as well. The classes
in `BKE_spline.hh` aim to be faster, more extensible, and much more
easily understandable. Further explanation can be found in comments in
that file.
Initial builtin spline attributes are supported-- reading and writing
from the `cyclic` and `resolution` attributes works with any of the
attribute nodes. Also, only Z-up normal calculation is implemented
at the moment, and tilts do not apply yet.
**Limitations**
- For now, you must bring curves into the node tree with an "Object
Info" node. Changes to the curve modifier stack will come later.
- Converting to a mesh is necessary to visualize the curve data.
Further progress can be tracked in: T87245
Higher level design document: https://wiki.blender.org/wiki/Modules/Physics_Nodes/Projects/EverythingNodes/CurveNodes
Differential Revision: https://developer.blender.org/D11091
2021-05-03 12:29:17 -05:00
|
|
|
{
|
2023-08-03 17:09:18 +02:00
|
|
|
const CurveComponent *component = this->get_component<CurveComponent>();
|
|
|
|
|
return (component == nullptr) ? nullptr : component->get();
|
Geometry Nodes: Initial basic curve data support
This patch adds initial curve support to geometry nodes. Currently
there is only one node available, the "Curve to Mesh" node, T87428.
However, the aim of the changes here is larger than just supporting
curve data in nodes-- it also uses the opportunity to add better spline
data structures, intended to replace the existing curve evaluation code.
The curve code in Blender is quite old, and it's generally regarded as
some of the messiest, hardest-to-understand code as well. The classes
in `BKE_spline.hh` aim to be faster, more extensible, and much more
easily understandable. Further explanation can be found in comments in
that file.
Initial builtin spline attributes are supported-- reading and writing
from the `cyclic` and `resolution` attributes works with any of the
attribute nodes. Also, only Z-up normal calculation is implemented
at the moment, and tilts do not apply yet.
**Limitations**
- For now, you must bring curves into the node tree with an "Object
Info" node. Changes to the curve modifier stack will come later.
- Converting to a mesh is necessary to visualize the curve data.
Further progress can be tracked in: T87245
Higher level design document: https://wiki.blender.org/wiki/Modules/Physics_Nodes/Projects/EverythingNodes/CurveNodes
Differential Revision: https://developer.blender.org/D11091
2021-05-03 12:29:17 -05:00
|
|
|
}
|
|
|
|
|
|
2023-08-03 17:09:18 +02:00
|
|
|
const Instances *GeometrySet::get_instances() const
|
2022-10-17 11:39:40 +02:00
|
|
|
{
|
2023-08-03 17:09:18 +02:00
|
|
|
const InstancesComponent *component = this->get_component<InstancesComponent>();
|
|
|
|
|
return (component == nullptr) ? nullptr : component->get();
|
2022-10-17 11:39:40 +02:00
|
|
|
}
|
|
|
|
|
|
2023-08-03 17:09:18 +02:00
|
|
|
const CurvesEditHints *GeometrySet::get_curve_edit_hints() const
|
2022-07-22 15:39:41 +02:00
|
|
|
{
|
2023-08-03 17:09:18 +02:00
|
|
|
const GeometryComponentEditData *component = this->get_component<GeometryComponentEditData>();
|
2022-07-22 15:39:41 +02:00
|
|
|
return (component == nullptr) ? nullptr : component->curves_edit_hints_.get();
|
|
|
|
|
}
|
|
|
|
|
|
Geometry Nodes: support attaching gizmos to input values
This adds support for attaching gizmos for input values. The goal is to make it
easier for users to set input values intuitively in the 3D viewport.
We went through multiple different possible designs until we settled on the one
implemented here. We picked it for it's flexibility and ease of use when using
geometry node assets. The core principle in the design is that **gizmos are
attached to existing input values instead of being the input value themselves**.
This actually fits the existing concept of gizmos in Blender well, but may be a
bit unintutitive in a node setup at first. The attachment is done using links in
the node editor.
The most basic usage of the node is to link a Value node to the new Linear Gizmo
node. This attaches the gizmo to the input value and allows you to change it
from the 3D view. The attachment is indicated by the gizmo icon in the sockets
which are controlled by a gizmo as well as the back-link (notice the double
link) when the gizmo is active.
The core principle makes it straight forward to control the same node setup from
the 3D view with gizmos, or by manually changing input values, or by driving the
input values procedurally.
If the input value is controlled indirectly by other inputs, it's often possible
to **automatically propagate** the gizmo to the actual input.
Backpropagation does not work for all nodes, although more nodes can be
supported over time.
This patch adds the first three gizmo nodes which cover common use cases:
* **Linear Gizmo**: Creates a gizmo that controls a float or integer value using
a linear movement of e.g. an arrow in the 3D viewport.
* **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be
rotated to change the attached angle input.
* **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale.
In the future, more built-in gizmos and potentially the ability for custom
gizmos could be added.
All gizmo nodes have a **Transform** geometry output. Using it is optional but
it is recommended when the gizmo is used to control inputs that affect a
geometry. When it is used, Blender will automatically transform the gizmos
together with the geometry that they control. To achieve this, the output should
be merged with the generated geometry using the *Join Geometry* node. The data
contained in *Transform* output is not visible geometry, but just internal
information that helps Blender to give a better user experience when using
gizmos.
The gizmo nodes have a multi-input socket. This allows **controlling multiple
values** with the same gizmo.
Only a small set of **gizmo shapes** is supported initially. It might be
extended in the future but one goal is to give the gizmos used by different node
group assets a familiar look and feel. A similar constraint exists for
**colors**. Currently, one can choose from a fixed set of colors which can be
modified in the theme settings.
The set of **visible gizmos** is determined by a multiple factors because it's
not really feasible to show all possible gizmos at all times. To see any of the
geometry nodes gizmos, the "Active Modifier" option has to be enabled in the
"Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of
the following is true:
* The gizmo controls an input of the active modifier of the active object.
* The gizmo controls a value in a selected node in an open node editor.
* The gizmo controls a pinned value in an open node editor. Pinning works by
clicking the gizmo icon next to the value.
Pull Request: https://projects.blender.org/blender/blender/pulls/112677
2024-07-10 16:18:47 +02:00
|
|
|
const GizmoEditHints *GeometrySet::get_gizmo_edit_hints() const
|
|
|
|
|
{
|
|
|
|
|
const GeometryComponentEditData *component = this->get_component<GeometryComponentEditData>();
|
|
|
|
|
return (component == nullptr) ? nullptr : component->gizmo_edit_hints_.get();
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-03 17:09:18 +02:00
|
|
|
const GreasePencil *GeometrySet::get_grease_pencil() const
|
2023-07-26 13:59:37 +02:00
|
|
|
{
|
2023-08-03 17:09:18 +02:00
|
|
|
const GreasePencilComponent *component = this->get_component<GreasePencilComponent>();
|
|
|
|
|
return (component == nullptr) ? nullptr : component->get();
|
2023-07-26 13:59:37 +02:00
|
|
|
}
|
|
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
bool GeometrySet::has_pointcloud() const
|
|
|
|
|
{
|
2023-08-03 17:09:18 +02:00
|
|
|
const PointCloudComponent *component = this->get_component<PointCloudComponent>();
|
2020-12-02 13:25:25 +01:00
|
|
|
return component != nullptr && component->has_pointcloud();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool GeometrySet::has_instances() const
|
|
|
|
|
{
|
2023-08-03 17:09:18 +02:00
|
|
|
const InstancesComponent *component = this->get_component<InstancesComponent>();
|
|
|
|
|
return component != nullptr && component->get() != nullptr &&
|
|
|
|
|
component->get()->instances_num() >= 1;
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
|
|
2021-01-21 10:32:42 +01:00
|
|
|
bool GeometrySet::has_volume() const
|
|
|
|
|
{
|
2023-08-03 17:09:18 +02:00
|
|
|
const VolumeComponent *component = this->get_component<VolumeComponent>();
|
2021-01-21 10:32:42 +01:00
|
|
|
return component != nullptr && component->has_volume();
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-28 10:53:30 -05:00
|
|
|
bool GeometrySet::has_curves() const
|
Geometry Nodes: Initial basic curve data support
This patch adds initial curve support to geometry nodes. Currently
there is only one node available, the "Curve to Mesh" node, T87428.
However, the aim of the changes here is larger than just supporting
curve data in nodes-- it also uses the opportunity to add better spline
data structures, intended to replace the existing curve evaluation code.
The curve code in Blender is quite old, and it's generally regarded as
some of the messiest, hardest-to-understand code as well. The classes
in `BKE_spline.hh` aim to be faster, more extensible, and much more
easily understandable. Further explanation can be found in comments in
that file.
Initial builtin spline attributes are supported-- reading and writing
from the `cyclic` and `resolution` attributes works with any of the
attribute nodes. Also, only Z-up normal calculation is implemented
at the moment, and tilts do not apply yet.
**Limitations**
- For now, you must bring curves into the node tree with an "Object
Info" node. Changes to the curve modifier stack will come later.
- Converting to a mesh is necessary to visualize the curve data.
Further progress can be tracked in: T87245
Higher level design document: https://wiki.blender.org/wiki/Modules/Physics_Nodes/Projects/EverythingNodes/CurveNodes
Differential Revision: https://developer.blender.org/D11091
2021-05-03 12:29:17 -05:00
|
|
|
{
|
2023-08-03 17:09:18 +02:00
|
|
|
const CurveComponent *component = this->get_component<CurveComponent>();
|
2022-02-28 10:46:34 -05:00
|
|
|
return component != nullptr && component->has_curves();
|
Geometry Nodes: Initial basic curve data support
This patch adds initial curve support to geometry nodes. Currently
there is only one node available, the "Curve to Mesh" node, T87428.
However, the aim of the changes here is larger than just supporting
curve data in nodes-- it also uses the opportunity to add better spline
data structures, intended to replace the existing curve evaluation code.
The curve code in Blender is quite old, and it's generally regarded as
some of the messiest, hardest-to-understand code as well. The classes
in `BKE_spline.hh` aim to be faster, more extensible, and much more
easily understandable. Further explanation can be found in comments in
that file.
Initial builtin spline attributes are supported-- reading and writing
from the `cyclic` and `resolution` attributes works with any of the
attribute nodes. Also, only Z-up normal calculation is implemented
at the moment, and tilts do not apply yet.
**Limitations**
- For now, you must bring curves into the node tree with an "Object
Info" node. Changes to the curve modifier stack will come later.
- Converting to a mesh is necessary to visualize the curve data.
Further progress can be tracked in: T87245
Higher level design document: https://wiki.blender.org/wiki/Modules/Physics_Nodes/Projects/EverythingNodes/CurveNodes
Differential Revision: https://developer.blender.org/D11091
2021-05-03 12:29:17 -05:00
|
|
|
}
|
|
|
|
|
|
2021-09-27 10:16:38 +02:00
|
|
|
bool GeometrySet::has_realized_data() const
|
|
|
|
|
{
|
2021-12-05 15:10:11 +01:00
|
|
|
for (const GeometryComponentPtr &component_ptr : components_) {
|
|
|
|
|
if (component_ptr) {
|
2023-06-15 22:18:28 +02:00
|
|
|
if (component_ptr->type() != GeometryComponent::Type::Instance) {
|
2021-12-05 15:10:11 +01:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
}
|
2021-09-27 10:16:38 +02:00
|
|
|
}
|
2021-12-05 15:10:11 +01:00
|
|
|
return false;
|
2021-09-27 10:16:38 +02:00
|
|
|
}
|
|
|
|
|
|
2023-07-26 13:59:37 +02:00
|
|
|
bool GeometrySet::has_grease_pencil() const
|
|
|
|
|
{
|
2023-08-03 17:09:18 +02:00
|
|
|
const GreasePencilComponent *component = this->get_component<GreasePencilComponent>();
|
2023-07-26 13:59:37 +02:00
|
|
|
return component != nullptr && component->has_grease_pencil();
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-28 11:36:28 -05:00
|
|
|
bool GeometrySet::is_empty() const
|
|
|
|
|
{
|
2022-02-28 10:53:30 -05:00
|
|
|
return !(this->has_mesh() || this->has_curves() || this->has_pointcloud() ||
|
2023-07-26 13:59:37 +02:00
|
|
|
this->has_volume() || this->has_instances() || this->has_grease_pencil());
|
2021-09-28 11:36:28 -05:00
|
|
|
}
|
|
|
|
|
|
2023-08-03 17:09:18 +02:00
|
|
|
GeometrySet GeometrySet::from_mesh(Mesh *mesh, GeometryOwnershipType ownership)
|
2020-12-02 13:25:25 +01:00
|
|
|
{
|
|
|
|
|
GeometrySet geometry_set;
|
2023-07-07 09:59:55 -04:00
|
|
|
geometry_set.replace_mesh(mesh, ownership);
|
2020-12-02 13:25:25 +01:00
|
|
|
return geometry_set;
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-03 17:09:18 +02:00
|
|
|
GeometrySet GeometrySet::from_volume(Volume *volume, GeometryOwnershipType ownership)
|
2022-06-29 10:56:17 -05:00
|
|
|
{
|
|
|
|
|
GeometrySet geometry_set;
|
2023-07-07 09:59:55 -04:00
|
|
|
geometry_set.replace_volume(volume, ownership);
|
2022-06-29 10:56:17 -05:00
|
|
|
return geometry_set;
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-03 17:09:18 +02:00
|
|
|
GeometrySet GeometrySet::from_pointcloud(PointCloud *pointcloud, GeometryOwnershipType ownership)
|
2020-12-02 13:25:25 +01:00
|
|
|
{
|
|
|
|
|
GeometrySet geometry_set;
|
2023-07-07 09:59:55 -04:00
|
|
|
geometry_set.replace_pointcloud(pointcloud, ownership);
|
2020-12-02 13:25:25 +01:00
|
|
|
return geometry_set;
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-03 17:09:18 +02:00
|
|
|
GeometrySet GeometrySet::from_curves(Curves *curves, GeometryOwnershipType ownership)
|
Geometry Nodes: Initial basic curve data support
This patch adds initial curve support to geometry nodes. Currently
there is only one node available, the "Curve to Mesh" node, T87428.
However, the aim of the changes here is larger than just supporting
curve data in nodes-- it also uses the opportunity to add better spline
data structures, intended to replace the existing curve evaluation code.
The curve code in Blender is quite old, and it's generally regarded as
some of the messiest, hardest-to-understand code as well. The classes
in `BKE_spline.hh` aim to be faster, more extensible, and much more
easily understandable. Further explanation can be found in comments in
that file.
Initial builtin spline attributes are supported-- reading and writing
from the `cyclic` and `resolution` attributes works with any of the
attribute nodes. Also, only Z-up normal calculation is implemented
at the moment, and tilts do not apply yet.
**Limitations**
- For now, you must bring curves into the node tree with an "Object
Info" node. Changes to the curve modifier stack will come later.
- Converting to a mesh is necessary to visualize the curve data.
Further progress can be tracked in: T87245
Higher level design document: https://wiki.blender.org/wiki/Modules/Physics_Nodes/Projects/EverythingNodes/CurveNodes
Differential Revision: https://developer.blender.org/D11091
2021-05-03 12:29:17 -05:00
|
|
|
{
|
|
|
|
|
GeometrySet geometry_set;
|
2023-07-07 09:59:55 -04:00
|
|
|
geometry_set.replace_curves(curves, ownership);
|
Geometry Nodes: Initial basic curve data support
This patch adds initial curve support to geometry nodes. Currently
there is only one node available, the "Curve to Mesh" node, T87428.
However, the aim of the changes here is larger than just supporting
curve data in nodes-- it also uses the opportunity to add better spline
data structures, intended to replace the existing curve evaluation code.
The curve code in Blender is quite old, and it's generally regarded as
some of the messiest, hardest-to-understand code as well. The classes
in `BKE_spline.hh` aim to be faster, more extensible, and much more
easily understandable. Further explanation can be found in comments in
that file.
Initial builtin spline attributes are supported-- reading and writing
from the `cyclic` and `resolution` attributes works with any of the
attribute nodes. Also, only Z-up normal calculation is implemented
at the moment, and tilts do not apply yet.
**Limitations**
- For now, you must bring curves into the node tree with an "Object
Info" node. Changes to the curve modifier stack will come later.
- Converting to a mesh is necessary to visualize the curve data.
Further progress can be tracked in: T87245
Higher level design document: https://wiki.blender.org/wiki/Modules/Physics_Nodes/Projects/EverythingNodes/CurveNodes
Differential Revision: https://developer.blender.org/D11091
2021-05-03 12:29:17 -05:00
|
|
|
return geometry_set;
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-03 17:09:18 +02:00
|
|
|
GeometrySet GeometrySet::from_instances(Instances *instances, GeometryOwnershipType ownership)
|
2022-10-17 11:39:40 +02:00
|
|
|
{
|
|
|
|
|
GeometrySet geometry_set;
|
|
|
|
|
geometry_set.replace_instances(instances, ownership);
|
|
|
|
|
return geometry_set;
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-03 17:09:18 +02:00
|
|
|
GeometrySet GeometrySet::from_grease_pencil(GreasePencil *grease_pencil,
|
|
|
|
|
GeometryOwnershipType ownership)
|
2023-07-26 13:59:37 +02:00
|
|
|
{
|
|
|
|
|
GeometrySet geometry_set;
|
|
|
|
|
geometry_set.replace_grease_pencil(grease_pencil, ownership);
|
|
|
|
|
return geometry_set;
|
|
|
|
|
}
|
|
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
void GeometrySet::replace_mesh(Mesh *mesh, GeometryOwnershipType ownership)
|
|
|
|
|
{
|
2021-10-14 12:43:36 -05:00
|
|
|
if (mesh == nullptr) {
|
|
|
|
|
this->remove<MeshComponent>();
|
2021-12-09 14:34:15 -06:00
|
|
|
return;
|
2021-10-14 12:43:36 -05:00
|
|
|
}
|
2023-08-03 17:09:18 +02:00
|
|
|
if (mesh == this->get_mesh()) {
|
2021-12-09 17:43:30 -06:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
this->remove<MeshComponent>();
|
2021-12-09 14:34:15 -06:00
|
|
|
MeshComponent &component = this->get_component_for_write<MeshComponent>();
|
|
|
|
|
component.replace(mesh, ownership);
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
|
|
2022-03-07 16:26:55 -06:00
|
|
|
void GeometrySet::replace_curves(Curves *curves, GeometryOwnershipType ownership)
|
Geometry Nodes: Initial basic curve data support
This patch adds initial curve support to geometry nodes. Currently
there is only one node available, the "Curve to Mesh" node, T87428.
However, the aim of the changes here is larger than just supporting
curve data in nodes-- it also uses the opportunity to add better spline
data structures, intended to replace the existing curve evaluation code.
The curve code in Blender is quite old, and it's generally regarded as
some of the messiest, hardest-to-understand code as well. The classes
in `BKE_spline.hh` aim to be faster, more extensible, and much more
easily understandable. Further explanation can be found in comments in
that file.
Initial builtin spline attributes are supported-- reading and writing
from the `cyclic` and `resolution` attributes works with any of the
attribute nodes. Also, only Z-up normal calculation is implemented
at the moment, and tilts do not apply yet.
**Limitations**
- For now, you must bring curves into the node tree with an "Object
Info" node. Changes to the curve modifier stack will come later.
- Converting to a mesh is necessary to visualize the curve data.
Further progress can be tracked in: T87245
Higher level design document: https://wiki.blender.org/wiki/Modules/Physics_Nodes/Projects/EverythingNodes/CurveNodes
Differential Revision: https://developer.blender.org/D11091
2021-05-03 12:29:17 -05:00
|
|
|
{
|
2022-02-28 10:46:34 -05:00
|
|
|
if (curves == nullptr) {
|
2021-10-14 12:43:36 -05:00
|
|
|
this->remove<CurveComponent>();
|
2021-12-09 14:34:15 -06:00
|
|
|
return;
|
2021-10-14 12:43:36 -05:00
|
|
|
}
|
2023-08-03 17:09:18 +02:00
|
|
|
if (curves == this->get_curves()) {
|
2021-12-09 17:43:30 -06:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
this->remove<CurveComponent>();
|
2021-12-09 14:34:15 -06:00
|
|
|
CurveComponent &component = this->get_component_for_write<CurveComponent>();
|
2022-02-28 10:46:34 -05:00
|
|
|
component.replace(curves, ownership);
|
Geometry Nodes: Initial basic curve data support
This patch adds initial curve support to geometry nodes. Currently
there is only one node available, the "Curve to Mesh" node, T87428.
However, the aim of the changes here is larger than just supporting
curve data in nodes-- it also uses the opportunity to add better spline
data structures, intended to replace the existing curve evaluation code.
The curve code in Blender is quite old, and it's generally regarded as
some of the messiest, hardest-to-understand code as well. The classes
in `BKE_spline.hh` aim to be faster, more extensible, and much more
easily understandable. Further explanation can be found in comments in
that file.
Initial builtin spline attributes are supported-- reading and writing
from the `cyclic` and `resolution` attributes works with any of the
attribute nodes. Also, only Z-up normal calculation is implemented
at the moment, and tilts do not apply yet.
**Limitations**
- For now, you must bring curves into the node tree with an "Object
Info" node. Changes to the curve modifier stack will come later.
- Converting to a mesh is necessary to visualize the curve data.
Further progress can be tracked in: T87245
Higher level design document: https://wiki.blender.org/wiki/Modules/Physics_Nodes/Projects/EverythingNodes/CurveNodes
Differential Revision: https://developer.blender.org/D11091
2021-05-03 12:29:17 -05:00
|
|
|
}
|
|
|
|
|
|
2022-10-17 11:39:40 +02:00
|
|
|
void GeometrySet::replace_instances(Instances *instances, GeometryOwnershipType ownership)
|
|
|
|
|
{
|
|
|
|
|
if (instances == nullptr) {
|
|
|
|
|
this->remove<InstancesComponent>();
|
|
|
|
|
return;
|
|
|
|
|
}
|
2023-08-03 17:09:18 +02:00
|
|
|
if (instances == this->get_instances()) {
|
2022-10-17 11:39:40 +02:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
this->remove<InstancesComponent>();
|
|
|
|
|
InstancesComponent &component = this->get_component_for_write<InstancesComponent>();
|
|
|
|
|
component.replace(instances, ownership);
|
|
|
|
|
}
|
|
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
void GeometrySet::replace_pointcloud(PointCloud *pointcloud, GeometryOwnershipType ownership)
|
|
|
|
|
{
|
2021-10-14 12:43:36 -05:00
|
|
|
if (pointcloud == nullptr) {
|
|
|
|
|
this->remove<PointCloudComponent>();
|
2021-12-09 14:34:15 -06:00
|
|
|
return;
|
2021-10-14 12:43:36 -05:00
|
|
|
}
|
2023-08-03 17:09:18 +02:00
|
|
|
if (pointcloud == this->get_pointcloud()) {
|
2021-12-09 17:43:30 -06:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
this->remove<PointCloudComponent>();
|
2021-12-09 14:34:15 -06:00
|
|
|
PointCloudComponent &component = this->get_component_for_write<PointCloudComponent>();
|
|
|
|
|
component.replace(pointcloud, ownership);
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
|
|
2021-04-26 14:42:03 -05:00
|
|
|
void GeometrySet::replace_volume(Volume *volume, GeometryOwnershipType ownership)
|
|
|
|
|
{
|
2021-10-14 12:43:36 -05:00
|
|
|
if (volume == nullptr) {
|
|
|
|
|
this->remove<VolumeComponent>();
|
2021-12-09 14:34:15 -06:00
|
|
|
return;
|
2021-10-14 12:43:36 -05:00
|
|
|
}
|
2023-08-03 17:09:18 +02:00
|
|
|
if (volume == this->get_volume()) {
|
2021-12-09 17:43:30 -06:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
this->remove<VolumeComponent>();
|
2021-12-09 14:34:15 -06:00
|
|
|
VolumeComponent &component = this->get_component_for_write<VolumeComponent>();
|
|
|
|
|
component.replace(volume, ownership);
|
2021-04-26 14:42:03 -05:00
|
|
|
}
|
|
|
|
|
|
2023-07-26 13:59:37 +02:00
|
|
|
void GeometrySet::replace_grease_pencil(GreasePencil *grease_pencil,
|
|
|
|
|
GeometryOwnershipType ownership)
|
|
|
|
|
{
|
|
|
|
|
if (grease_pencil == nullptr) {
|
|
|
|
|
this->remove<GreasePencilComponent>();
|
|
|
|
|
return;
|
|
|
|
|
}
|
2023-08-03 17:09:18 +02:00
|
|
|
if (grease_pencil == this->get_grease_pencil()) {
|
2023-07-26 13:59:37 +02:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
this->remove<GreasePencilComponent>();
|
|
|
|
|
GreasePencilComponent &component = this->get_component_for_write<GreasePencilComponent>();
|
|
|
|
|
component.replace(grease_pencil, ownership);
|
|
|
|
|
}
|
|
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
Mesh *GeometrySet::get_mesh_for_write()
|
|
|
|
|
{
|
2021-10-14 12:43:36 -05:00
|
|
|
MeshComponent *component = this->get_component_ptr<MeshComponent>();
|
|
|
|
|
return component == nullptr ? nullptr : component->get_for_write();
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PointCloud *GeometrySet::get_pointcloud_for_write()
|
|
|
|
|
{
|
2021-10-14 12:43:36 -05:00
|
|
|
PointCloudComponent *component = this->get_component_ptr<PointCloudComponent>();
|
|
|
|
|
return component == nullptr ? nullptr : component->get_for_write();
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
|
|
2021-01-21 10:32:42 +01:00
|
|
|
Volume *GeometrySet::get_volume_for_write()
|
|
|
|
|
{
|
2021-10-14 12:43:36 -05:00
|
|
|
VolumeComponent *component = this->get_component_ptr<VolumeComponent>();
|
|
|
|
|
return component == nullptr ? nullptr : component->get_for_write();
|
2021-01-21 10:32:42 +01:00
|
|
|
}
|
|
|
|
|
|
2022-02-28 10:53:30 -05:00
|
|
|
Curves *GeometrySet::get_curves_for_write()
|
Geometry Nodes: Initial basic curve data support
This patch adds initial curve support to geometry nodes. Currently
there is only one node available, the "Curve to Mesh" node, T87428.
However, the aim of the changes here is larger than just supporting
curve data in nodes-- it also uses the opportunity to add better spline
data structures, intended to replace the existing curve evaluation code.
The curve code in Blender is quite old, and it's generally regarded as
some of the messiest, hardest-to-understand code as well. The classes
in `BKE_spline.hh` aim to be faster, more extensible, and much more
easily understandable. Further explanation can be found in comments in
that file.
Initial builtin spline attributes are supported-- reading and writing
from the `cyclic` and `resolution` attributes works with any of the
attribute nodes. Also, only Z-up normal calculation is implemented
at the moment, and tilts do not apply yet.
**Limitations**
- For now, you must bring curves into the node tree with an "Object
Info" node. Changes to the curve modifier stack will come later.
- Converting to a mesh is necessary to visualize the curve data.
Further progress can be tracked in: T87245
Higher level design document: https://wiki.blender.org/wiki/Modules/Physics_Nodes/Projects/EverythingNodes/CurveNodes
Differential Revision: https://developer.blender.org/D11091
2021-05-03 12:29:17 -05:00
|
|
|
{
|
2021-10-14 12:43:36 -05:00
|
|
|
CurveComponent *component = this->get_component_ptr<CurveComponent>();
|
|
|
|
|
return component == nullptr ? nullptr : component->get_for_write();
|
Geometry Nodes: Initial basic curve data support
This patch adds initial curve support to geometry nodes. Currently
there is only one node available, the "Curve to Mesh" node, T87428.
However, the aim of the changes here is larger than just supporting
curve data in nodes-- it also uses the opportunity to add better spline
data structures, intended to replace the existing curve evaluation code.
The curve code in Blender is quite old, and it's generally regarded as
some of the messiest, hardest-to-understand code as well. The classes
in `BKE_spline.hh` aim to be faster, more extensible, and much more
easily understandable. Further explanation can be found in comments in
that file.
Initial builtin spline attributes are supported-- reading and writing
from the `cyclic` and `resolution` attributes works with any of the
attribute nodes. Also, only Z-up normal calculation is implemented
at the moment, and tilts do not apply yet.
**Limitations**
- For now, you must bring curves into the node tree with an "Object
Info" node. Changes to the curve modifier stack will come later.
- Converting to a mesh is necessary to visualize the curve data.
Further progress can be tracked in: T87245
Higher level design document: https://wiki.blender.org/wiki/Modules/Physics_Nodes/Projects/EverythingNodes/CurveNodes
Differential Revision: https://developer.blender.org/D11091
2021-05-03 12:29:17 -05:00
|
|
|
}
|
|
|
|
|
|
2022-10-17 11:39:40 +02:00
|
|
|
Instances *GeometrySet::get_instances_for_write()
|
|
|
|
|
{
|
|
|
|
|
InstancesComponent *component = this->get_component_ptr<InstancesComponent>();
|
|
|
|
|
return component == nullptr ? nullptr : component->get_for_write();
|
|
|
|
|
}
|
|
|
|
|
|
2023-06-15 22:18:28 +02:00
|
|
|
CurvesEditHints *GeometrySet::get_curve_edit_hints_for_write()
|
2022-07-22 15:39:41 +02:00
|
|
|
{
|
|
|
|
|
if (!this->has<GeometryComponentEditData>()) {
|
|
|
|
|
return nullptr;
|
|
|
|
|
}
|
|
|
|
|
GeometryComponentEditData &component =
|
|
|
|
|
this->get_component_for_write<GeometryComponentEditData>();
|
|
|
|
|
return component.curves_edit_hints_.get();
|
|
|
|
|
}
|
|
|
|
|
|
Geometry Nodes: support attaching gizmos to input values
This adds support for attaching gizmos for input values. The goal is to make it
easier for users to set input values intuitively in the 3D viewport.
We went through multiple different possible designs until we settled on the one
implemented here. We picked it for it's flexibility and ease of use when using
geometry node assets. The core principle in the design is that **gizmos are
attached to existing input values instead of being the input value themselves**.
This actually fits the existing concept of gizmos in Blender well, but may be a
bit unintutitive in a node setup at first. The attachment is done using links in
the node editor.
The most basic usage of the node is to link a Value node to the new Linear Gizmo
node. This attaches the gizmo to the input value and allows you to change it
from the 3D view. The attachment is indicated by the gizmo icon in the sockets
which are controlled by a gizmo as well as the back-link (notice the double
link) when the gizmo is active.
The core principle makes it straight forward to control the same node setup from
the 3D view with gizmos, or by manually changing input values, or by driving the
input values procedurally.
If the input value is controlled indirectly by other inputs, it's often possible
to **automatically propagate** the gizmo to the actual input.
Backpropagation does not work for all nodes, although more nodes can be
supported over time.
This patch adds the first three gizmo nodes which cover common use cases:
* **Linear Gizmo**: Creates a gizmo that controls a float or integer value using
a linear movement of e.g. an arrow in the 3D viewport.
* **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be
rotated to change the attached angle input.
* **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale.
In the future, more built-in gizmos and potentially the ability for custom
gizmos could be added.
All gizmo nodes have a **Transform** geometry output. Using it is optional but
it is recommended when the gizmo is used to control inputs that affect a
geometry. When it is used, Blender will automatically transform the gizmos
together with the geometry that they control. To achieve this, the output should
be merged with the generated geometry using the *Join Geometry* node. The data
contained in *Transform* output is not visible geometry, but just internal
information that helps Blender to give a better user experience when using
gizmos.
The gizmo nodes have a multi-input socket. This allows **controlling multiple
values** with the same gizmo.
Only a small set of **gizmo shapes** is supported initially. It might be
extended in the future but one goal is to give the gizmos used by different node
group assets a familiar look and feel. A similar constraint exists for
**colors**. Currently, one can choose from a fixed set of colors which can be
modified in the theme settings.
The set of **visible gizmos** is determined by a multiple factors because it's
not really feasible to show all possible gizmos at all times. To see any of the
geometry nodes gizmos, the "Active Modifier" option has to be enabled in the
"Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of
the following is true:
* The gizmo controls an input of the active modifier of the active object.
* The gizmo controls a value in a selected node in an open node editor.
* The gizmo controls a pinned value in an open node editor. Pinning works by
clicking the gizmo icon next to the value.
Pull Request: https://projects.blender.org/blender/blender/pulls/112677
2024-07-10 16:18:47 +02:00
|
|
|
GizmoEditHints *GeometrySet::get_gizmo_edit_hints_for_write()
|
|
|
|
|
{
|
|
|
|
|
if (!this->has<GeometryComponentEditData>()) {
|
|
|
|
|
return nullptr;
|
|
|
|
|
}
|
|
|
|
|
GeometryComponentEditData &component =
|
|
|
|
|
this->get_component_for_write<GeometryComponentEditData>();
|
|
|
|
|
return component.gizmo_edit_hints_.get();
|
|
|
|
|
}
|
|
|
|
|
|
2023-07-26 13:59:37 +02:00
|
|
|
GreasePencil *GeometrySet::get_grease_pencil_for_write()
|
|
|
|
|
{
|
|
|
|
|
GreasePencilComponent *component = this->get_component_ptr<GreasePencilComponent>();
|
|
|
|
|
return component == nullptr ? nullptr : component->get_for_write();
|
|
|
|
|
}
|
|
|
|
|
|
Core: introduce MemoryCounter API
We often have the situation where it would be good if we could easily estimate
the memory usage of some value (e.g. a mesh, or volume). Examples of where we
ran into this in the past:
* Undo step size.
* Caching of volume grids.
* Caching of loaded geometries for import geometry nodes.
Generally, most caching systems would benefit from the ability to know how much
memory they currently use to make better decisions about which data to free and
when. The goal of this patch is to introduce a simple general API to count the
memory usage that is independent of any specific caching system. I'm doing this
to "fix" the chicken and egg problem that caches need to know the memory usage,
but we don't really need to count the memory usage without using it for caches.
Implementing caching and memory counting at the same time make both harder than
implementing them one after another.
The main difficulty with counting memory usage is that some memory may be shared
using implicit sharing. We want to avoid double counting such memory. How
exactly shared memory is treated depends a bit on the use case, so no specific
assumptions are made about that in the API. The gathered memory usage is not
expected to be exact. It's expected to be a decent approximation. It's neither a
lower nor an upper bound unless specified by some specific type. Cache systems
generally build on top of heuristics to decide when to free what anyway.
There are two sides to this API:
1. Get the amount of memory used by one or more values. This side is used by
caching systems and/or systems that want to present the used memory to the
user.
2. Tell the caller how much memory is used. This side is used by all kinds of
types that can report their memory usage such as meshes.
```cpp
/* Get how much memory is used by two meshes together. */
MemoryCounter memory;
mesh_a->count_memory(memory);
mesh_b->count_memory(memory);
int64_t bytes_used = memory.counted_bytes();
/* Tell the caller how much memory is used. */
void Mesh::count_memory(blender::MemoryCounter &memory) const
{
memory.add_shared(this->runtime->face_offsets_sharing_info,
this->face_offsets().size_in_bytes());
/* Forward memory counting to lower level types. This should be fairly common. */
CustomData_count_memory(this->vert_data, this->verts_num, memory);
}
void CustomData_count_memory(const CustomData &data,
const int totelem,
blender::MemoryCounter &memory)
{
for (const CustomDataLayer &layer : Span{data.layers, data.totlayer}) {
memory.add_shared(layer.sharing_info, [&](blender::MemoryCounter &shared_memory) {
/* Not quite correct for all types, but this is only a rough approximation anyway. */
const int64_t elem_size = CustomData_get_elem_size(&layer);
shared_memory.add(totelem * elem_size);
});
}
}
```
Pull Request: https://projects.blender.org/blender/blender/pulls/126295
2024-08-15 10:54:21 +02:00
|
|
|
void GeometrySet::count_memory(MemoryCounter &memory) const
|
|
|
|
|
{
|
|
|
|
|
for (const GeometryComponentPtr &component : components_) {
|
|
|
|
|
if (component) {
|
|
|
|
|
memory.add_shared(component.get(), [&](MemoryCounter &shared_memory) {
|
|
|
|
|
component->count_memory(shared_memory);
|
|
|
|
|
});
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-06-15 22:18:28 +02:00
|
|
|
void GeometrySet::attribute_foreach(const Span<GeometryComponent::Type> component_types,
|
2021-09-23 17:50:33 +02:00
|
|
|
const bool include_instances,
|
|
|
|
|
const AttributeForeachCallback callback) const
|
|
|
|
|
{
|
2023-06-15 22:18:28 +02:00
|
|
|
for (const GeometryComponent::Type component_type : component_types) {
|
2021-09-23 17:50:33 +02:00
|
|
|
if (!this->has(component_type)) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
2023-08-03 17:09:18 +02:00
|
|
|
const GeometryComponent &component = *this->get_component(component_type);
|
Geometry Nodes: new geometry attribute API
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
2022-07-08 16:16:56 +02:00
|
|
|
const std::optional<AttributeAccessor> attributes = component.attributes();
|
|
|
|
|
if (attributes.has_value()) {
|
2024-09-26 12:59:00 +02:00
|
|
|
attributes->foreach_attribute([&](const AttributeIter &iter) {
|
|
|
|
|
callback(iter.name, {iter.domain, iter.data_type}, component);
|
2024-09-04 16:13:03 +02:00
|
|
|
});
|
Geometry Nodes: new geometry attribute API
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
2022-07-08 16:16:56 +02:00
|
|
|
}
|
2021-09-23 17:50:33 +02:00
|
|
|
}
|
|
|
|
|
if (include_instances && this->has_instances()) {
|
2023-08-03 17:09:18 +02:00
|
|
|
const Instances &instances = *this->get_instances();
|
2021-09-23 17:50:33 +02:00
|
|
|
instances.foreach_referenced_geometry([&](const GeometrySet &instance_geometry_set) {
|
|
|
|
|
instance_geometry_set.attribute_foreach(component_types, include_instances, callback);
|
|
|
|
|
});
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-13 10:08:51 +02:00
|
|
|
void GeometrySet::propagate_attributes_from_layer_to_instances(
|
|
|
|
|
const AttributeAccessor src_attributes,
|
|
|
|
|
MutableAttributeAccessor dst_attributes,
|
2024-09-05 11:33:35 +02:00
|
|
|
const AttributeFilter &attribute_filter)
|
2023-10-13 10:08:51 +02:00
|
|
|
{
|
2024-09-26 12:59:00 +02:00
|
|
|
src_attributes.foreach_attribute([&](const AttributeIter &iter) {
|
|
|
|
|
if (attribute_filter.allow_skip(iter.name)) {
|
|
|
|
|
return;
|
2023-10-13 10:08:51 +02:00
|
|
|
}
|
2024-09-26 12:59:00 +02:00
|
|
|
const GAttributeReader src = iter.get(AttrDomain::Layer);
|
2023-10-13 10:08:51 +02:00
|
|
|
if (src.sharing_info && src.varray.is_span()) {
|
|
|
|
|
const AttributeInitShared init(src.varray.get_internal_span().data(), *src.sharing_info);
|
2024-09-26 12:59:00 +02:00
|
|
|
if (dst_attributes.add(iter.name, AttrDomain::Instance, iter.data_type, init)) {
|
|
|
|
|
return;
|
2023-10-13 10:08:51 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
GSpanAttributeWriter dst = dst_attributes.lookup_or_add_for_write_only_span(
|
2024-09-26 12:59:00 +02:00
|
|
|
iter.name, AttrDomain::Instance, iter.data_type);
|
2023-10-13 10:08:51 +02:00
|
|
|
if (!dst) {
|
2024-09-26 12:59:00 +02:00
|
|
|
return;
|
2023-10-13 10:08:51 +02:00
|
|
|
}
|
|
|
|
|
array_utils::copy(src.varray, dst.span);
|
|
|
|
|
dst.finish();
|
|
|
|
|
});
|
|
|
|
|
}
|
|
|
|
|
|
2024-10-07 14:10:32 +02:00
|
|
|
bool attribute_is_builtin_on_component_type(const GeometryComponent::Type type,
|
|
|
|
|
const StringRef name)
|
|
|
|
|
{
|
|
|
|
|
switch (type) {
|
|
|
|
|
case GeometryComponent::Type::Mesh: {
|
|
|
|
|
static auto component = GeometryComponent::create(type);
|
|
|
|
|
return component->attributes()->is_builtin(name);
|
|
|
|
|
}
|
|
|
|
|
case GeometryComponent::Type::PointCloud: {
|
|
|
|
|
static auto component = GeometryComponent::create(type);
|
|
|
|
|
return component->attributes()->is_builtin(name);
|
|
|
|
|
}
|
|
|
|
|
case GeometryComponent::Type::Instance: {
|
|
|
|
|
static auto component = GeometryComponent::create(type);
|
|
|
|
|
return component->attributes()->is_builtin(name);
|
|
|
|
|
}
|
|
|
|
|
case GeometryComponent::Type::Curve: {
|
|
|
|
|
static auto component = GeometryComponent::create(type);
|
|
|
|
|
return component->attributes()->is_builtin(name);
|
|
|
|
|
}
|
|
|
|
|
case GeometryComponent::Type::GreasePencil: {
|
|
|
|
|
static auto grease_pencil_component = GeometryComponent::create(
|
|
|
|
|
GeometryComponent::Type::GreasePencil);
|
|
|
|
|
static auto curves_component = GeometryComponent::create(GeometryComponent::Type::Curve);
|
|
|
|
|
return grease_pencil_component->attributes()->is_builtin(name) ||
|
|
|
|
|
curves_component->attributes()->is_builtin(name);
|
|
|
|
|
}
|
|
|
|
|
case GeometryComponent::Type::Volume:
|
|
|
|
|
case GeometryComponent::Type::Edit: {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
BLI_assert_unreachable();
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-23 17:50:33 +02:00
|
|
|
void GeometrySet::gather_attributes_for_propagation(
|
2023-06-15 22:18:28 +02:00
|
|
|
const Span<GeometryComponent::Type> component_types,
|
|
|
|
|
const GeometryComponent::Type dst_component_type,
|
2021-09-23 17:50:33 +02:00
|
|
|
bool include_instances,
|
2024-09-05 11:33:35 +02:00
|
|
|
const AttributeFilter &attribute_filter,
|
2024-09-04 16:13:03 +02:00
|
|
|
Map<StringRef, AttributeKind> &r_attributes) const
|
2021-09-23 17:50:33 +02:00
|
|
|
{
|
|
|
|
|
this->attribute_foreach(
|
|
|
|
|
component_types,
|
|
|
|
|
include_instances,
|
2024-09-04 16:13:03 +02:00
|
|
|
[&](const StringRef attribute_id,
|
2021-09-23 17:50:33 +02:00
|
|
|
const AttributeMetaData &meta_data,
|
|
|
|
|
const GeometryComponent &component) {
|
Geometry Nodes: new geometry attribute API
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
2022-07-08 16:16:56 +02:00
|
|
|
if (component.attributes()->is_builtin(attribute_id)) {
|
2024-10-07 14:10:32 +02:00
|
|
|
if (!attribute_is_builtin_on_component_type(dst_component_type, attribute_id)) {
|
2021-09-23 17:50:33 +02:00
|
|
|
/* Don't propagate built-in attributes that are not built-in on the destination
|
|
|
|
|
* component. */
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
2022-10-18 17:16:51 +02:00
|
|
|
if (meta_data.data_type == CD_PROP_STRING) {
|
|
|
|
|
/* Propagating string attributes is not supported yet. */
|
|
|
|
|
return;
|
|
|
|
|
}
|
2024-09-05 11:33:35 +02:00
|
|
|
if (attribute_filter.allow_skip(attribute_id)) {
|
2021-10-20 09:57:54 -05:00
|
|
|
return;
|
2021-09-23 17:50:33 +02:00
|
|
|
}
|
2021-10-20 09:57:54 -05:00
|
|
|
|
2023-12-20 13:13:16 -05:00
|
|
|
AttrDomain domain = meta_data.domain;
|
2023-06-15 22:18:28 +02:00
|
|
|
if (dst_component_type != GeometryComponent::Type::Instance &&
|
2023-12-20 13:13:16 -05:00
|
|
|
domain == AttrDomain::Instance) {
|
|
|
|
|
domain = AttrDomain::Point;
|
Geometry Nodes: support instance attributes when realizing instances
This patch refactors the instance-realization code and adds new functionality.
* Named and anonymous attributes are propagated from instances to the
realized geometry. If the same attribute exists on the geometry and on an
instance, the attribute on the geometry has precedence.
* The id attribute has special handling to avoid creating the same id on many
output points. This is necessary to make e.g. the Random Value node work
as expected afterwards.
Realizing instance attributes has an effect on existing files, especially due to the
id attribute. To avoid breaking existing files, the Realize Instances node now has
a legacy option that is enabled for all already existing Realize Instances nodes.
Removing this legacy behavior does affect some existing files (although not many).
We can decide whether it's worth to remove the old behavior as a separate step.
This refactor also improves performance when realizing instances. That is mainly
due to multi-threading. See D13446 to get the file used for benchmarking. The
curve code is not as optimized as it could be yet. That's mainly because the storage
for these attributes might change soonish and it wasn't worth optimizing for the
current storage format right now.
```
1,000,000 x mesh vertex: 530 ms -> 130 ms
1,000,000 x simple cube: 1290 ms -> 190 ms
1,000,000 x point: 1000 ms -> 150 ms
1,000,000 x curve spiral: 1740 ms -> 330 ms
1,000,000 x curve line: 1110 ms -> 210 ms
10,000 x subdivided cylinder: 170 ms -> 40 ms
10 x subdivided spiral: 180 ms -> 180 ms
```
Differential Revision: https://developer.blender.org/D13446
2021-12-14 15:57:58 +01:00
|
|
|
}
|
|
|
|
|
|
2021-09-23 17:50:33 +02:00
|
|
|
auto add_info = [&](AttributeKind *attribute_kind) {
|
Geometry Nodes: support instance attributes when realizing instances
This patch refactors the instance-realization code and adds new functionality.
* Named and anonymous attributes are propagated from instances to the
realized geometry. If the same attribute exists on the geometry and on an
instance, the attribute on the geometry has precedence.
* The id attribute has special handling to avoid creating the same id on many
output points. This is necessary to make e.g. the Random Value node work
as expected afterwards.
Realizing instance attributes has an effect on existing files, especially due to the
id attribute. To avoid breaking existing files, the Realize Instances node now has
a legacy option that is enabled for all already existing Realize Instances nodes.
Removing this legacy behavior does affect some existing files (although not many).
We can decide whether it's worth to remove the old behavior as a separate step.
This refactor also improves performance when realizing instances. That is mainly
due to multi-threading. See D13446 to get the file used for benchmarking. The
curve code is not as optimized as it could be yet. That's mainly because the storage
for these attributes might change soonish and it wasn't worth optimizing for the
current storage format right now.
```
1,000,000 x mesh vertex: 530 ms -> 130 ms
1,000,000 x simple cube: 1290 ms -> 190 ms
1,000,000 x point: 1000 ms -> 150 ms
1,000,000 x curve spiral: 1740 ms -> 330 ms
1,000,000 x curve line: 1110 ms -> 210 ms
10,000 x subdivided cylinder: 170 ms -> 40 ms
10 x subdivided spiral: 180 ms -> 180 ms
```
Differential Revision: https://developer.blender.org/D13446
2021-12-14 15:57:58 +01:00
|
|
|
attribute_kind->domain = domain;
|
2021-09-23 17:50:33 +02:00
|
|
|
attribute_kind->data_type = meta_data.data_type;
|
|
|
|
|
};
|
|
|
|
|
auto modify_info = [&](AttributeKind *attribute_kind) {
|
|
|
|
|
attribute_kind->domain = bke::attribute_domain_highest_priority(
|
Geometry Nodes: support instance attributes when realizing instances
This patch refactors the instance-realization code and adds new functionality.
* Named and anonymous attributes are propagated from instances to the
realized geometry. If the same attribute exists on the geometry and on an
instance, the attribute on the geometry has precedence.
* The id attribute has special handling to avoid creating the same id on many
output points. This is necessary to make e.g. the Random Value node work
as expected afterwards.
Realizing instance attributes has an effect on existing files, especially due to the
id attribute. To avoid breaking existing files, the Realize Instances node now has
a legacy option that is enabled for all already existing Realize Instances nodes.
Removing this legacy behavior does affect some existing files (although not many).
We can decide whether it's worth to remove the old behavior as a separate step.
This refactor also improves performance when realizing instances. That is mainly
due to multi-threading. See D13446 to get the file used for benchmarking. The
curve code is not as optimized as it could be yet. That's mainly because the storage
for these attributes might change soonish and it wasn't worth optimizing for the
current storage format right now.
```
1,000,000 x mesh vertex: 530 ms -> 130 ms
1,000,000 x simple cube: 1290 ms -> 190 ms
1,000,000 x point: 1000 ms -> 150 ms
1,000,000 x curve spiral: 1740 ms -> 330 ms
1,000,000 x curve line: 1110 ms -> 210 ms
10,000 x subdivided cylinder: 170 ms -> 40 ms
10 x subdivided spiral: 180 ms -> 180 ms
```
Differential Revision: https://developer.blender.org/D13446
2021-12-14 15:57:58 +01:00
|
|
|
{attribute_kind->domain, domain});
|
2021-09-23 17:50:33 +02:00
|
|
|
attribute_kind->data_type = bke::attribute_data_type_highest_complexity(
|
|
|
|
|
{attribute_kind->data_type, meta_data.data_type});
|
|
|
|
|
};
|
|
|
|
|
r_attributes.add_or_modify(attribute_id, add_info, modify_info);
|
|
|
|
|
});
|
|
|
|
|
}
|
|
|
|
|
|
2021-10-26 20:00:03 +02:00
|
|
|
static void gather_component_types_recursive(const GeometrySet &geometry_set,
|
|
|
|
|
const bool include_instances,
|
|
|
|
|
const bool ignore_empty,
|
2023-06-15 22:18:28 +02:00
|
|
|
Vector<GeometryComponent::Type> &r_types)
|
2021-10-26 20:00:03 +02:00
|
|
|
{
|
2023-08-03 17:09:18 +02:00
|
|
|
for (const GeometryComponent *component : geometry_set.get_components()) {
|
2021-10-26 20:00:03 +02:00
|
|
|
if (ignore_empty) {
|
|
|
|
|
if (component->is_empty()) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
r_types.append_non_duplicates(component->type());
|
|
|
|
|
}
|
|
|
|
|
if (!include_instances) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
2023-08-03 17:09:18 +02:00
|
|
|
const Instances *instances = geometry_set.get_instances();
|
2021-10-26 20:00:03 +02:00
|
|
|
if (instances == nullptr) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
instances->foreach_referenced_geometry([&](const GeometrySet &instance_geometry_set) {
|
|
|
|
|
gather_component_types_recursive(
|
|
|
|
|
instance_geometry_set, include_instances, ignore_empty, r_types);
|
|
|
|
|
});
|
|
|
|
|
}
|
|
|
|
|
|
2023-06-15 22:18:28 +02:00
|
|
|
Vector<GeometryComponent::Type> GeometrySet::gather_component_types(const bool include_instances,
|
|
|
|
|
bool ignore_empty) const
|
2021-10-26 20:00:03 +02:00
|
|
|
{
|
2023-06-15 22:18:28 +02:00
|
|
|
Vector<GeometryComponent::Type> types;
|
2021-10-26 20:00:03 +02:00
|
|
|
gather_component_types_recursive(*this, include_instances, ignore_empty, types);
|
|
|
|
|
return types;
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-28 10:17:00 +02:00
|
|
|
static void gather_mutable_geometry_sets(GeometrySet &geometry_set,
|
|
|
|
|
Vector<GeometrySet *> &r_geometry_sets)
|
2021-09-27 17:35:26 +02:00
|
|
|
{
|
2021-09-28 10:17:00 +02:00
|
|
|
r_geometry_sets.append(&geometry_set);
|
|
|
|
|
if (!geometry_set.has_instances()) {
|
2021-09-27 17:35:26 +02:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
/* In the future this can be improved by deduplicating instance references across different
|
|
|
|
|
* instances. */
|
2022-10-17 11:39:40 +02:00
|
|
|
Instances &instances = *geometry_set.get_instances_for_write();
|
|
|
|
|
instances.ensure_geometry_instances();
|
|
|
|
|
for (const int handle : instances.references().index_range()) {
|
|
|
|
|
if (instances.references()[handle].type() == InstanceReference::Type::GeometrySet) {
|
|
|
|
|
GeometrySet &instance_geometry = instances.geometry_set_from_reference(handle);
|
2021-09-28 10:17:00 +02:00
|
|
|
gather_mutable_geometry_sets(instance_geometry, r_geometry_sets);
|
2021-09-27 17:35:26 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-28 10:17:00 +02:00
|
|
|
void GeometrySet::modify_geometry_sets(ForeachSubGeometryCallback callback)
|
|
|
|
|
{
|
|
|
|
|
Vector<GeometrySet *> geometry_sets;
|
|
|
|
|
gather_mutable_geometry_sets(*this, geometry_sets);
|
2022-04-26 09:24:18 -05:00
|
|
|
if (geometry_sets.size() == 1) {
|
|
|
|
|
/* Avoid possible overhead and a large call stack when multithreading is pointless. */
|
|
|
|
|
callback(*geometry_sets.first());
|
|
|
|
|
}
|
|
|
|
|
else {
|
2023-06-15 22:18:28 +02:00
|
|
|
threading::parallel_for_each(geometry_sets,
|
|
|
|
|
[&](GeometrySet *geometry_set) { callback(*geometry_set); });
|
2022-04-26 09:24:18 -05:00
|
|
|
}
|
2021-09-28 10:17:00 +02:00
|
|
|
}
|
|
|
|
|
|
2023-06-15 22:18:28 +02:00
|
|
|
bool object_has_geometry_set_instances(const Object &object)
|
2020-12-02 13:25:25 +01:00
|
|
|
{
|
2023-11-15 18:46:07 +01:00
|
|
|
const GeometrySet *geometry_set = object.runtime->geometry_set_eval;
|
2021-09-06 18:22:24 +02:00
|
|
|
if (geometry_set == nullptr) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2024-08-17 00:58:37 +02:00
|
|
|
if (geometry_set->has_component<InstancesComponent>()) {
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
if (object.type != OB_MESH && geometry_set->has_component<MeshComponent>()) {
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
if (object.type != OB_POINTCLOUD && geometry_set->has_component<PointCloudComponent>()) {
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
if (object.type != OB_VOLUME && geometry_set->has_component<VolumeComponent>()) {
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
if (!ELEM(object.type, OB_CURVES_LEGACY, OB_FONT) &&
|
|
|
|
|
geometry_set->has_component<CurveComponent>())
|
|
|
|
|
{
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
if (object.type != OB_GREASE_PENCIL && geometry_set->has_component<GreasePencilComponent>()) {
|
|
|
|
|
return true;
|
2021-09-06 18:22:24 +02:00
|
|
|
}
|
|
|
|
|
return false;
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/** \} */
|
2023-07-09 21:40:17 +10:00
|
|
|
|
|
|
|
|
} // namespace blender::bke
|