archive/blender-archive
Archived
1
1
Fork 0
Code Pull Requests Packages Activity
This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
ab063db34d60bdda6a683b13cef36d93ad6e760f
blender-archive/source/blender/blenkernel/BKE_geometry_set.hh

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

592 lines
22 KiB
C++
Raw Normal View History

Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
/*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*/
#pragma once
/** \file
* \ingroup bke
*/
#include <atomic>
#include <iostream>
#include "BLI_float3.hh"
Fix T85049: Geometry Nodes: How to handle instances with shear? Use transform matrices instead of loc, rot, scale variables to store instance transforms. Reviewed By: JacquesLucke Differential Revision: http://developer.blender.org/D10211
2021-01-26 18:21:12 +01:00
#include "BLI_float4x4.hh"
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
#include "BLI_hash.hh"
#include "BLI_map.hh"
#include "BLI_set.hh"
#include "BLI_user_counter.hh"
Geometry Nodes: refactor instances component The main goal of this refactor is to not store Object/Collection pointers for every individual instance. Instead instances now store a handle for the referenced data. The actual Object/Collection pointers are stored in a new `InstanceReference` class. This refactor also allows for some better optimizations further down the line, because one does not have to search through all instances anymore to find what data is instanced. Furthermore, this refactor makes it easier to support instancing `GeometrySet` or any other data that has to be owned by the `InstancesComponent`. Differential Revision: https://developer.blender.org/D11125
2021-05-04 10:16:24 +02:00
#include "BLI_vector_set.hh"
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
#include "BKE_attribute_access.hh"
#include "BKE_geometry_set.h"
Cleanup: sort struct blocks
2020-12-16 16:26:23 +11:00
struct Collection;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
struct Mesh;
struct Object;
Cleanup: sort struct blocks
2020-12-16 16:26:23 +11:00
struct PointCloud;
Geometry Nodes: initial support for volumes For the most part, this just adds boilerplate code for volume support in geometry nodes: * Add `VolumeComponent` next to `MeshComponent`, etc. * Support `VolumeComponent` in depsgraph object iterator. Furthermore, I added initial volume support in a few nodes: * The Object Info node outputs an object instance when the input is a volume object (that will be the same for mesh objects soonish, to avoid copies). * Support transforming a `VolumeComponent` in the Transform node. * Support the `VolumeComponent` in Join Geometry nodes, but only when just one of the inputs has a volume component for now. Right now, there is no way to create a `VolumeComponent`, because the Object Info node outputs an object instance. The `VolumeComponent` will be necessary for upcoming nodes, which will generate volumes on the fly. Viewport selection does not work correctly with `VolumeComponent`s currently. I don't know why that is. That can be figured out a bit later, once we can actually create new volumes in geometry nodes. Ref T84604. Differential Revision: https://developer.blender.org/D10147
2021-01-21 10:32:42 +01:00
struct Volume;
Geometry Nodes: Draw curve data in the viewport This patch adds relatively small changes to the curve draw cache implementation in order to draw the curve data in the viewport. The dependency graph iterator is also modified so that it iterates over the curve geometry component, which is presented to users as `Curve` data with a pointer to the `CurveEval` The idea with the spline data type in geometry nodes is that curve data itself is only the control points, and any evaluated data with faces is a mesh. That is mostly expected elsewhere in Blender anyway. This means it's only necessary to implement wire edge drawing of `CurveEval` data. Adding a `CurveEval` pointer to `Curve` is in line with changes I'd like to make in the future like using `CurveEval` in more places such as edit mode. An alternate solution involves converting the curve wire data to a mesh, however, that requires copying all of the data, and since avoiding it is rather simple and is in-line with future plans anyway, I think doing it this way is better. Differential Revision: https://developer.blender.org/D11351
2021-05-27 10:08:40 -04:00
struct Curve;
Cleanup: Fix forward declaring class with "struct"
2021-05-27 11:00:00 -04:00
struct CurveEval;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
enum class GeometryOwnershipType {
/* The geometry is owned. This implies that it can be changed. */
Owned = 0,
/* The geometry can be changed, but someone else is responsible for freeing it. */
Editable = 1,
/* The geometry cannot be changed and someone else is responsible for freeing it. */
ReadOnly = 2,
};
Geometry Nodes: refactor internal attribute access architecture Goals: * Clarify the distinction between builtin and other attributes at the code level. * Reduce number of places that need to be modified to add more builtin attributes. * Reduce number of virtual methods that need to be implemented by e.g. `MeshComponent`. To achieve these goals, this patch implements the concept of "attribute providers". An attribute provider knows how to give access to attributes on a geometry component. Each geometry component can have multiple attribute providers, whereby each provider manages an different set of attributes. The separation of builtin and other attributes is now done at the attribute provider level. There are two types of attribute providers. One for builtin attributes and one for all others. This refactor also helps with T84297. Differential Revision: https://developer.blender.org/D10341
2021-02-09 11:24:28 +01:00
namespace blender::bke {
Fix: use class instead of struct in forward declaration
2021-02-09 11:47:49 +01:00
class ComponentAttributeProviders;
Geometry Nodes: refactor internal attribute access architecture Goals: * Clarify the distinction between builtin and other attributes at the code level. * Reduce number of places that need to be modified to add more builtin attributes. * Reduce number of virtual methods that need to be implemented by e.g. `MeshComponent`. To achieve these goals, this patch implements the concept of "attribute providers". An attribute provider knows how to give access to attributes on a geometry component. Each geometry component can have multiple attribute providers, whereby each provider manages an different set of attributes. The separation of builtin and other attributes is now done at the attribute provider level. There are two types of attribute providers. One for builtin attributes and one for all others. This refactor also helps with T84297. Differential Revision: https://developer.blender.org/D10341
2021-02-09 11:24:28 +01:00
}
Geometry Nodes: don't delete existing attribute before new attribute is computed This fixes the behavior of some nodes when the same attribute name is used for input and output. If both attributes have a different type, they can't exist at the same time. Therefore, the input attribute has to be removed in order to create the output attribute. Previously, the input attribute was remove before it was used in any computations. Now, the output is written to a temporary buffer and only later saved in the geometry component. This allows both attributes to coexist within the node. The temporary attribute is only create when necessary. The normal case without name collisions still works the same as before. Differential Revision: https://developer.blender.org/D10109 Ref T83793.
2021-01-14 15:52:08 +01:00
class GeometryComponent;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
/**
* This is the base class for specialized geometry component types.
*/
class GeometryComponent {
private:
/* The reference count has two purposes. When it becomes zero, the component is freed. When it is
* larger than one, the component becomes immutable. */
mutable std::atomic<int> users_ = 1;
GeometryComponentType type_;
public:
GeometryComponent(GeometryComponentType type);
Cleanup: enable modernize-use-equals-default check This removes a lot of unnecessary code that is generated by the compiler automatically. In very few cases, a defaulted destructor in a .cc file is still necessary, because of forward declarations in the header. I removed some defaulted virtual destructors, because they are not necessary, when the parent class has a virtual destructor already. Defaulted constructors are only necessary when there is another constructor, but the class should still be default constructible. Differential Revision: https://developer.blender.org/D10911
2021-04-08 11:07:12 +02:00
virtual ~GeometryComponent() = default;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
static GeometryComponent *create(GeometryComponentType component_type);
/* The returned component should be of the same type as the type this is called on. */
virtual GeometryComponent *copy() const = 0;
Spreadsheet: support showing data of specific node Previously, the spreadsheet editor could only show data of the original and of the final evaluated object. Now it is possible to show the data at some intermediate stages too. For that the mode has to be set to "Node" in the spreadsheet editor. Furthermore, the preview of a specific node has to be activated by clicking the new icon in the header of geometry nodes. The exact ui of this feature might be refined in upcoming commits. It is already very useful for debugging node groups in it's current state though. Differential Revision: https://developer.blender.org/D10875
2021-04-08 17:35:06 +02:00
/* Direct data is everything except for instances of objects/collections.
* If this returns true, the geometry set can be cached and is still valid after e.g. modifier
* evaluation ends. Instances can only be valid as long as the data they instance is valid. */
virtual bool owns_direct_data() const = 0;
virtual void ensure_owns_direct_data() = 0;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
void user_add() const;
void user_remove() const;
bool is_mutable() const;
GeometryComponentType type() const;
Geometry Nodes: Add helper function to check if attribute exists
2020-12-10 10:50:37 -06:00
/* Return true when any attribute with this name exists, including built in attributes. */
bool attribute_exists(const blender::StringRef attribute_name) const;
Geometry Nodes: Get attribute domain and type without allocation Because we use virtual classes (and for other reasons), we had to do a small allocation when simply retrieving the data type and domain of an existing attribute. This happened quite a lot actually-- to determine these values for result attributes. This patch adds a simple function to retrieve this meta data without building the virtual array. This should lower the overhead of every attribute node, though the difference probably won't be noticible unless a tree has very many nodes. Differential Revision: https://developer.blender.org/D11047
2021-04-22 08:05:02 -05:00
/* Return the data type and domain of an attribute with the given name if it exists. */
std::optional<AttributeMetaData> attribute_get_meta_data(
const blender::StringRef attribute_name) const;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
/* Returns true when the geometry component supports this attribute domain. */
Geometry Nodes: refactor internal attribute access architecture Goals: * Clarify the distinction between builtin and other attributes at the code level. * Reduce number of places that need to be modified to add more builtin attributes. * Reduce number of virtual methods that need to be implemented by e.g. `MeshComponent`. To achieve these goals, this patch implements the concept of "attribute providers". An attribute provider knows how to give access to attributes on a geometry component. Each geometry component can have multiple attribute providers, whereby each provider manages an different set of attributes. The separation of builtin and other attributes is now done at the attribute provider level. There are two types of attribute providers. One for builtin attributes and one for all others. This refactor also helps with T84297. Differential Revision: https://developer.blender.org/D10341
2021-02-09 11:24:28 +01:00
bool attribute_domain_supported(const AttributeDomain domain) const;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
/* Can only be used with supported domain types. */
virtual int attribute_domain_size(const AttributeDomain domain) const;
Geometry Nodes: use virtual arrays in internal attribute api A virtual array is a data structure that is similar to a normal array in that its elements can be accessed by an index. However, a virtual array does not have to be a contiguous array internally. Instead, its elements can be layed out arbitrarily while element access happens through a virtual function call. However, the virtual array data structures are designed so that the virtual function call can be avoided in cases where it could become a bottleneck. Most commonly, a virtual array is backed by an actual array/span or is a single value internally, that is the same for every index. Besides those, there are many more specialized virtual arrays like the ones that provides vertex positions based on the `MVert` struct or vertex group weights. Not all attributes used by geometry nodes are stored in simple contiguous arrays. To provide uniform access to all kinds of attributes, the attribute API has to provide virtual array functionality that hides the implementation details of attributes. Before this refactor, the attribute API provided its own virtual array implementation as part of the `ReadAttribute` and `WriteAttribute` types. That resulted in unnecessary code duplication with the virtual array system. Even worse, it bound many algorithms used by geometry nodes to the specifics of the attribute API, even though they could also use different data sources (such as data from sockets, default values, later results of expressions, ...). This refactor removes the `ReadAttribute` and `WriteAttribute` types and replaces them with `GVArray` and `GVMutableArray` respectively. The `GV` stands for "generic virtual". The "generic" means that the data type contained in those virtual arrays is only known at run-time. There are the corresponding statically typed types `VArray<T>` and `VMutableArray<T>` as well. No regressions are expected from this refactor. It does come with one improvement for users. The attribute API can convert the data type on write now. This is especially useful when writing to builtin attributes like `material_index` with e.g. the Attribute Math node (which usually just writes to float attributes, while `material_index` is an integer attribute). Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
bool attribute_is_builtin(const blender::StringRef attribute_name) const;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
/* Get read-only access to the highest priority attribute with the given name.
* Returns null if the attribute does not exist. */
Geometry Nodes: use virtual arrays in internal attribute api A virtual array is a data structure that is similar to a normal array in that its elements can be accessed by an index. However, a virtual array does not have to be a contiguous array internally. Instead, its elements can be layed out arbitrarily while element access happens through a virtual function call. However, the virtual array data structures are designed so that the virtual function call can be avoided in cases where it could become a bottleneck. Most commonly, a virtual array is backed by an actual array/span or is a single value internally, that is the same for every index. Besides those, there are many more specialized virtual arrays like the ones that provides vertex positions based on the `MVert` struct or vertex group weights. Not all attributes used by geometry nodes are stored in simple contiguous arrays. To provide uniform access to all kinds of attributes, the attribute API has to provide virtual array functionality that hides the implementation details of attributes. Before this refactor, the attribute API provided its own virtual array implementation as part of the `ReadAttribute` and `WriteAttribute` types. That resulted in unnecessary code duplication with the virtual array system. Even worse, it bound many algorithms used by geometry nodes to the specifics of the attribute API, even though they could also use different data sources (such as data from sockets, default values, later results of expressions, ...). This refactor removes the `ReadAttribute` and `WriteAttribute` types and replaces them with `GVArray` and `GVMutableArray` respectively. The `GV` stands for "generic virtual". The "generic" means that the data type contained in those virtual arrays is only known at run-time. There are the corresponding statically typed types `VArray<T>` and `VMutableArray<T>` as well. No regressions are expected from this refactor. It does come with one improvement for users. The attribute API can convert the data type on write now. This is especially useful when writing to builtin attributes like `material_index` with e.g. the Attribute Math node (which usually just writes to float attributes, while `material_index` is an integer attribute). Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
blender::bke::ReadAttributeLookup attribute_try_get_for_read(
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
const blender::StringRef attribute_name) const;
/* Get read and write access to the highest priority attribute with the given name.
* Returns null if the attribute does not exist. */
Geometry Nodes: use virtual arrays in internal attribute api A virtual array is a data structure that is similar to a normal array in that its elements can be accessed by an index. However, a virtual array does not have to be a contiguous array internally. Instead, its elements can be layed out arbitrarily while element access happens through a virtual function call. However, the virtual array data structures are designed so that the virtual function call can be avoided in cases where it could become a bottleneck. Most commonly, a virtual array is backed by an actual array/span or is a single value internally, that is the same for every index. Besides those, there are many more specialized virtual arrays like the ones that provides vertex positions based on the `MVert` struct or vertex group weights. Not all attributes used by geometry nodes are stored in simple contiguous arrays. To provide uniform access to all kinds of attributes, the attribute API has to provide virtual array functionality that hides the implementation details of attributes. Before this refactor, the attribute API provided its own virtual array implementation as part of the `ReadAttribute` and `WriteAttribute` types. That resulted in unnecessary code duplication with the virtual array system. Even worse, it bound many algorithms used by geometry nodes to the specifics of the attribute API, even though they could also use different data sources (such as data from sockets, default values, later results of expressions, ...). This refactor removes the `ReadAttribute` and `WriteAttribute` types and replaces them with `GVArray` and `GVMutableArray` respectively. The `GV` stands for "generic virtual". The "generic" means that the data type contained in those virtual arrays is only known at run-time. There are the corresponding statically typed types `VArray<T>` and `VMutableArray<T>` as well. No regressions are expected from this refactor. It does come with one improvement for users. The attribute API can convert the data type on write now. This is especially useful when writing to builtin attributes like `material_index` with e.g. the Attribute Math node (which usually just writes to float attributes, while `material_index` is an integer attribute). Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
blender::bke::WriteAttributeLookup attribute_try_get_for_write(
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
const blender::StringRef attribute_name);
/* Get a read-only attribute for the domain based on the given attribute. This can be used to
* interpolate from one domain to another.
* Returns null if the interpolation is not implemented. */
Geometry Nodes: use virtual arrays in internal attribute api A virtual array is a data structure that is similar to a normal array in that its elements can be accessed by an index. However, a virtual array does not have to be a contiguous array internally. Instead, its elements can be layed out arbitrarily while element access happens through a virtual function call. However, the virtual array data structures are designed so that the virtual function call can be avoided in cases where it could become a bottleneck. Most commonly, a virtual array is backed by an actual array/span or is a single value internally, that is the same for every index. Besides those, there are many more specialized virtual arrays like the ones that provides vertex positions based on the `MVert` struct or vertex group weights. Not all attributes used by geometry nodes are stored in simple contiguous arrays. To provide uniform access to all kinds of attributes, the attribute API has to provide virtual array functionality that hides the implementation details of attributes. Before this refactor, the attribute API provided its own virtual array implementation as part of the `ReadAttribute` and `WriteAttribute` types. That resulted in unnecessary code duplication with the virtual array system. Even worse, it bound many algorithms used by geometry nodes to the specifics of the attribute API, even though they could also use different data sources (such as data from sockets, default values, later results of expressions, ...). This refactor removes the `ReadAttribute` and `WriteAttribute` types and replaces them with `GVArray` and `GVMutableArray` respectively. The `GV` stands for "generic virtual". The "generic" means that the data type contained in those virtual arrays is only known at run-time. There are the corresponding statically typed types `VArray<T>` and `VMutableArray<T>` as well. No regressions are expected from this refactor. It does come with one improvement for users. The attribute API can convert the data type on write now. This is especially useful when writing to builtin attributes like `material_index` with e.g. the Attribute Math node (which usually just writes to float attributes, while `material_index` is an integer attribute). Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
virtual std::unique_ptr<blender::fn::GVArray> attribute_try_adapt_domain(
std::unique_ptr<blender::fn::GVArray> varray,
const AttributeDomain from_domain,
const AttributeDomain to_domain) const;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
/* Returns true when the attribute has been deleted. */
Geometry Nodes: refactor internal attribute access architecture Goals: * Clarify the distinction between builtin and other attributes at the code level. * Reduce number of places that need to be modified to add more builtin attributes. * Reduce number of virtual methods that need to be implemented by e.g. `MeshComponent`. To achieve these goals, this patch implements the concept of "attribute providers". An attribute provider knows how to give access to attributes on a geometry component. Each geometry component can have multiple attribute providers, whereby each provider manages an different set of attributes. The separation of builtin and other attributes is now done at the attribute provider level. There are two types of attribute providers. One for builtin attributes and one for all others. This refactor also helps with T84297. Differential Revision: https://developer.blender.org/D10341
2021-02-09 11:24:28 +01:00
bool attribute_try_delete(const blender::StringRef attribute_name);
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
/* Returns true when the attribute has been created. */
Geometry Nodes: refactor internal attribute access architecture Goals: * Clarify the distinction between builtin and other attributes at the code level. * Reduce number of places that need to be modified to add more builtin attributes. * Reduce number of virtual methods that need to be implemented by e.g. `MeshComponent`. To achieve these goals, this patch implements the concept of "attribute providers". An attribute provider knows how to give access to attributes on a geometry component. Each geometry component can have multiple attribute providers, whereby each provider manages an different set of attributes. The separation of builtin and other attributes is now done at the attribute provider level. There are two types of attribute providers. One for builtin attributes and one for all others. This refactor also helps with T84297. Differential Revision: https://developer.blender.org/D10341
2021-02-09 11:24:28 +01:00
bool attribute_try_create(const blender::StringRef attribute_name,
const AttributeDomain domain,
Geometry Nodes: Add initializer for attribute creation Previously we always had to set attribute values after creating the attribute. This patch adds an initializer argument to `attribute_try_create` which can fill it in a few ways, which are explained in code comments. This fixes T87597. Differential Revision: https://developer.blender.org/D11045
2021-04-22 09:20:03 -05:00
const CustomDataType data_type,
const AttributeInit &initializer);
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
Geometry Nodes: use virtual arrays in internal attribute api A virtual array is a data structure that is similar to a normal array in that its elements can be accessed by an index. However, a virtual array does not have to be a contiguous array internally. Instead, its elements can be layed out arbitrarily while element access happens through a virtual function call. However, the virtual array data structures are designed so that the virtual function call can be avoided in cases where it could become a bottleneck. Most commonly, a virtual array is backed by an actual array/span or is a single value internally, that is the same for every index. Besides those, there are many more specialized virtual arrays like the ones that provides vertex positions based on the `MVert` struct or vertex group weights. Not all attributes used by geometry nodes are stored in simple contiguous arrays. To provide uniform access to all kinds of attributes, the attribute API has to provide virtual array functionality that hides the implementation details of attributes. Before this refactor, the attribute API provided its own virtual array implementation as part of the `ReadAttribute` and `WriteAttribute` types. That resulted in unnecessary code duplication with the virtual array system. Even worse, it bound many algorithms used by geometry nodes to the specifics of the attribute API, even though they could also use different data sources (such as data from sockets, default values, later results of expressions, ...). This refactor removes the `ReadAttribute` and `WriteAttribute` types and replaces them with `GVArray` and `GVMutableArray` respectively. The `GV` stands for "generic virtual". The "generic" means that the data type contained in those virtual arrays is only known at run-time. There are the corresponding statically typed types `VArray<T>` and `VMutableArray<T>` as well. No regressions are expected from this refactor. It does come with one improvement for users. The attribute API can convert the data type on write now. This is especially useful when writing to builtin attributes like `material_index` with e.g. the Attribute Math node (which usually just writes to float attributes, while `material_index` is an integer attribute). Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
/* Try to create the builtin attribute with the given name. No data type or domain has to be
* provided, because those are fixed for builtin attributes. */
Geometry Nodes: Add initializer for attribute creation Previously we always had to set attribute values after creating the attribute. This patch adds an initializer argument to `attribute_try_create` which can fill it in a few ways, which are explained in code comments. This fixes T87597. Differential Revision: https://developer.blender.org/D11045
2021-04-22 09:20:03 -05:00
bool attribute_try_create_builtin(const blender::StringRef attribute_name,
const AttributeInit &initializer);
Geometry Nodes: use virtual arrays in internal attribute api A virtual array is a data structure that is similar to a normal array in that its elements can be accessed by an index. However, a virtual array does not have to be a contiguous array internally. Instead, its elements can be layed out arbitrarily while element access happens through a virtual function call. However, the virtual array data structures are designed so that the virtual function call can be avoided in cases where it could become a bottleneck. Most commonly, a virtual array is backed by an actual array/span or is a single value internally, that is the same for every index. Besides those, there are many more specialized virtual arrays like the ones that provides vertex positions based on the `MVert` struct or vertex group weights. Not all attributes used by geometry nodes are stored in simple contiguous arrays. To provide uniform access to all kinds of attributes, the attribute API has to provide virtual array functionality that hides the implementation details of attributes. Before this refactor, the attribute API provided its own virtual array implementation as part of the `ReadAttribute` and `WriteAttribute` types. That resulted in unnecessary code duplication with the virtual array system. Even worse, it bound many algorithms used by geometry nodes to the specifics of the attribute API, even though they could also use different data sources (such as data from sockets, default values, later results of expressions, ...). This refactor removes the `ReadAttribute` and `WriteAttribute` types and replaces them with `GVArray` and `GVMutableArray` respectively. The `GV` stands for "generic virtual". The "generic" means that the data type contained in those virtual arrays is only known at run-time. There are the corresponding statically typed types `VArray<T>` and `VMutableArray<T>` as well. No regressions are expected from this refactor. It does come with one improvement for users. The attribute API can convert the data type on write now. This is especially useful when writing to builtin attributes like `material_index` with e.g. the Attribute Math node (which usually just writes to float attributes, while `material_index` is an integer attribute). Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
Geometry Nodes: refactor internal attribute access architecture Goals: * Clarify the distinction between builtin and other attributes at the code level. * Reduce number of places that need to be modified to add more builtin attributes. * Reduce number of virtual methods that need to be implemented by e.g. `MeshComponent`. To achieve these goals, this patch implements the concept of "attribute providers". An attribute provider knows how to give access to attributes on a geometry component. Each geometry component can have multiple attribute providers, whereby each provider manages an different set of attributes. The separation of builtin and other attributes is now done at the attribute provider level. There are two types of attribute providers. One for builtin attributes and one for all others. This refactor also helps with T84297. Differential Revision: https://developer.blender.org/D10341
2021-02-09 11:24:28 +01:00
blender::Set<std::string> attribute_names() const;
Geometry Nodes: Support instances in attribute search Previously only attributes of "real" geometry were displayed in attribute search. This commit adds code to look through attributes on instances and add those to the search drop-down too. This required implementing the same sort of recursive traversal as the realize instances code. The situation is a bit different though, this can return early and doesn't need to keep track of transforms. I added a limit so that it doesn't look through the attributes of too many instanced geometry sets. I think this is important, since this isn't a trivial operation and it could potentially happen for every node in a large node tree. Currently the limit is set at 8 geometry sets, which I expect will be enough, since the set of attributes is mostly not very unique anyway. Fixes T86282 Diffrential Revision: https://developer.blender.org/D10919
2021-04-08 12:19:09 -05:00
bool attribute_foreach(const AttributeForeachCallback callback) const;
Geometry Nodes: improve accessing attribute meta data This allows accessing attribute meta data like domain and data type without having to create a `ReadAttribute`. I kept the `attribute_names` method for now to keep the patch more self contained. Differential Revision: https://developer.blender.org/D10511
2021-02-23 15:15:23 +01:00
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
virtual bool is_empty() const;
Geometry Nodes: use virtual arrays in internal attribute api A virtual array is a data structure that is similar to a normal array in that its elements can be accessed by an index. However, a virtual array does not have to be a contiguous array internally. Instead, its elements can be layed out arbitrarily while element access happens through a virtual function call. However, the virtual array data structures are designed so that the virtual function call can be avoided in cases where it could become a bottleneck. Most commonly, a virtual array is backed by an actual array/span or is a single value internally, that is the same for every index. Besides those, there are many more specialized virtual arrays like the ones that provides vertex positions based on the `MVert` struct or vertex group weights. Not all attributes used by geometry nodes are stored in simple contiguous arrays. To provide uniform access to all kinds of attributes, the attribute API has to provide virtual array functionality that hides the implementation details of attributes. Before this refactor, the attribute API provided its own virtual array implementation as part of the `ReadAttribute` and `WriteAttribute` types. That resulted in unnecessary code duplication with the virtual array system. Even worse, it bound many algorithms used by geometry nodes to the specifics of the attribute API, even though they could also use different data sources (such as data from sockets, default values, later results of expressions, ...). This refactor removes the `ReadAttribute` and `WriteAttribute` types and replaces them with `GVArray` and `GVMutableArray` respectively. The `GV` stands for "generic virtual". The "generic" means that the data type contained in those virtual arrays is only known at run-time. There are the corresponding statically typed types `VArray<T>` and `VMutableArray<T>` as well. No regressions are expected from this refactor. It does come with one improvement for users. The attribute API can convert the data type on write now. This is especially useful when writing to builtin attributes like `material_index` with e.g. the Attribute Math node (which usually just writes to float attributes, while `material_index` is an integer attribute). Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
/* Get a virtual array to read the data of an attribute on the given domain and data type.
* Returns null when the attribute does not exist or cannot be converted to the requested domain
* and data type. */
std::unique_ptr<blender::fn::GVArray> attribute_try_get_for_read(
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
const blender::StringRef attribute_name,
const AttributeDomain domain,
const CustomDataType data_type) const;
Geometry Nodes: use virtual arrays in internal attribute api A virtual array is a data structure that is similar to a normal array in that its elements can be accessed by an index. However, a virtual array does not have to be a contiguous array internally. Instead, its elements can be layed out arbitrarily while element access happens through a virtual function call. However, the virtual array data structures are designed so that the virtual function call can be avoided in cases where it could become a bottleneck. Most commonly, a virtual array is backed by an actual array/span or is a single value internally, that is the same for every index. Besides those, there are many more specialized virtual arrays like the ones that provides vertex positions based on the `MVert` struct or vertex group weights. Not all attributes used by geometry nodes are stored in simple contiguous arrays. To provide uniform access to all kinds of attributes, the attribute API has to provide virtual array functionality that hides the implementation details of attributes. Before this refactor, the attribute API provided its own virtual array implementation as part of the `ReadAttribute` and `WriteAttribute` types. That resulted in unnecessary code duplication with the virtual array system. Even worse, it bound many algorithms used by geometry nodes to the specifics of the attribute API, even though they could also use different data sources (such as data from sockets, default values, later results of expressions, ...). This refactor removes the `ReadAttribute` and `WriteAttribute` types and replaces them with `GVArray` and `GVMutableArray` respectively. The `GV` stands for "generic virtual". The "generic" means that the data type contained in those virtual arrays is only known at run-time. There are the corresponding statically typed types `VArray<T>` and `VMutableArray<T>` as well. No regressions are expected from this refactor. It does come with one improvement for users. The attribute API can convert the data type on write now. This is especially useful when writing to builtin attributes like `material_index` with e.g. the Attribute Math node (which usually just writes to float attributes, while `material_index` is an integer attribute). Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
/* Get a virtual array to read the data of an attribute on the given domain. The data type is
* left unchanged. Returns null when the attribute does not exist or cannot be adapted to the
* requested domain. */
std::unique_ptr<blender::fn::GVArray> attribute_try_get_for_read(
Geometry Nodes: Make random attribute node stable Currently, the random attribute node doesn't work well for most workflows because for any change in the input data it outputs completely different results. This patch adds an implicit seed attribute input to the node, referred to by "id". The attribute is hashed for each element using the CPPType system's hash method, meaning the attribute can have any data type. Supporting any data type is also important so any attribute can be copied into the "id" attribute and used as a seed. The "id" attribute is an example of a "reserved name" attribute, meaning attributes with this name can be used implicitly by nodes like the random attribute node. Although it makes it a bit more difficult to dig deeper, using the name implicitly rather than exposing it as an input should make the system more accessible and predictable. Differential Revision: https://developer.blender.org/D9832
2020-12-17 07:43:31 -06:00
const blender::StringRef attribute_name, const AttributeDomain domain) const;
Geometry Nodes: add method to get attribute by name and type This is needed by the upcoming Attribute Transfer node. It changes its behavior based on what domain the attribute is on.
2021-04-21 17:07:00 +02:00
/* Get a virtual array to read data of an attribute with the given data type. The domain is
* left unchanged. Returns null when the attribute does not exist or cannot be converted to the
* requested data type. */
blender::bke::ReadAttributeLookup attribute_try_get_for_read(
const blender::StringRef attribute_name, const CustomDataType data_type) const;
Geometry Nodes: use virtual arrays in internal attribute api A virtual array is a data structure that is similar to a normal array in that its elements can be accessed by an index. However, a virtual array does not have to be a contiguous array internally. Instead, its elements can be layed out arbitrarily while element access happens through a virtual function call. However, the virtual array data structures are designed so that the virtual function call can be avoided in cases where it could become a bottleneck. Most commonly, a virtual array is backed by an actual array/span or is a single value internally, that is the same for every index. Besides those, there are many more specialized virtual arrays like the ones that provides vertex positions based on the `MVert` struct or vertex group weights. Not all attributes used by geometry nodes are stored in simple contiguous arrays. To provide uniform access to all kinds of attributes, the attribute API has to provide virtual array functionality that hides the implementation details of attributes. Before this refactor, the attribute API provided its own virtual array implementation as part of the `ReadAttribute` and `WriteAttribute` types. That resulted in unnecessary code duplication with the virtual array system. Even worse, it bound many algorithms used by geometry nodes to the specifics of the attribute API, even though they could also use different data sources (such as data from sockets, default values, later results of expressions, ...). This refactor removes the `ReadAttribute` and `WriteAttribute` types and replaces them with `GVArray` and `GVMutableArray` respectively. The `GV` stands for "generic virtual". The "generic" means that the data type contained in those virtual arrays is only known at run-time. There are the corresponding statically typed types `VArray<T>` and `VMutableArray<T>` as well. No regressions are expected from this refactor. It does come with one improvement for users. The attribute API can convert the data type on write now. This is especially useful when writing to builtin attributes like `material_index` with e.g. the Attribute Math node (which usually just writes to float attributes, while `material_index` is an integer attribute). Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
/* Get a virtual array to read the data of an attribute. If that is not possible, the returned
* virtual array will contain a default value. This never returns null. */
std::unique_ptr<blender::fn::GVArray> attribute_get_for_read(
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
const blender::StringRef attribute_name,
const AttributeDomain domain,
Geometry Nodes: use virtual arrays in internal attribute api A virtual array is a data structure that is similar to a normal array in that its elements can be accessed by an index. However, a virtual array does not have to be a contiguous array internally. Instead, its elements can be layed out arbitrarily while element access happens through a virtual function call. However, the virtual array data structures are designed so that the virtual function call can be avoided in cases where it could become a bottleneck. Most commonly, a virtual array is backed by an actual array/span or is a single value internally, that is the same for every index. Besides those, there are many more specialized virtual arrays like the ones that provides vertex positions based on the `MVert` struct or vertex group weights. Not all attributes used by geometry nodes are stored in simple contiguous arrays. To provide uniform access to all kinds of attributes, the attribute API has to provide virtual array functionality that hides the implementation details of attributes. Before this refactor, the attribute API provided its own virtual array implementation as part of the `ReadAttribute` and `WriteAttribute` types. That resulted in unnecessary code duplication with the virtual array system. Even worse, it bound many algorithms used by geometry nodes to the specifics of the attribute API, even though they could also use different data sources (such as data from sockets, default values, later results of expressions, ...). This refactor removes the `ReadAttribute` and `WriteAttribute` types and replaces them with `GVArray` and `GVMutableArray` respectively. The `GV` stands for "generic virtual". The "generic" means that the data type contained in those virtual arrays is only known at run-time. There are the corresponding statically typed types `VArray<T>` and `VMutableArray<T>` as well. No regressions are expected from this refactor. It does come with one improvement for users. The attribute API can convert the data type on write now. This is especially useful when writing to builtin attributes like `material_index` with e.g. the Attribute Math node (which usually just writes to float attributes, while `material_index` is an integer attribute). Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
const CustomDataType data_type,
const void *default_value = nullptr) const;
/* Should be used instead of the method above when the requested data type is known at compile
* time for better type safety. */
template<typename T>
blender::fn::GVArray_Typed<T> attribute_get_for_read(const blender::StringRef attribute_name,
const AttributeDomain domain,
const T &default_value) const
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
{
const blender::fn::CPPType &cpp_type = blender::fn::CPPType::get<T>();
const CustomDataType type = blender::bke::cpp_type_to_custom_data_type(cpp_type);
Geometry Nodes: use virtual arrays in internal attribute api A virtual array is a data structure that is similar to a normal array in that its elements can be accessed by an index. However, a virtual array does not have to be a contiguous array internally. Instead, its elements can be layed out arbitrarily while element access happens through a virtual function call. However, the virtual array data structures are designed so that the virtual function call can be avoided in cases where it could become a bottleneck. Most commonly, a virtual array is backed by an actual array/span or is a single value internally, that is the same for every index. Besides those, there are many more specialized virtual arrays like the ones that provides vertex positions based on the `MVert` struct or vertex group weights. Not all attributes used by geometry nodes are stored in simple contiguous arrays. To provide uniform access to all kinds of attributes, the attribute API has to provide virtual array functionality that hides the implementation details of attributes. Before this refactor, the attribute API provided its own virtual array implementation as part of the `ReadAttribute` and `WriteAttribute` types. That resulted in unnecessary code duplication with the virtual array system. Even worse, it bound many algorithms used by geometry nodes to the specifics of the attribute API, even though they could also use different data sources (such as data from sockets, default values, later results of expressions, ...). This refactor removes the `ReadAttribute` and `WriteAttribute` types and replaces them with `GVArray` and `GVMutableArray` respectively. The `GV` stands for "generic virtual". The "generic" means that the data type contained in those virtual arrays is only known at run-time. There are the corresponding statically typed types `VArray<T>` and `VMutableArray<T>` as well. No regressions are expected from this refactor. It does come with one improvement for users. The attribute API can convert the data type on write now. This is especially useful when writing to builtin attributes like `material_index` with e.g. the Attribute Math node (which usually just writes to float attributes, while `material_index` is an integer attribute). Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
std::unique_ptr varray = this->attribute_get_for_read(
attribute_name, domain, type, &default_value);
return blender::fn::GVArray_Typed<T>(std::move(varray));
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
}
Geometry Nodes: use virtual arrays in internal attribute api A virtual array is a data structure that is similar to a normal array in that its elements can be accessed by an index. However, a virtual array does not have to be a contiguous array internally. Instead, its elements can be layed out arbitrarily while element access happens through a virtual function call. However, the virtual array data structures are designed so that the virtual function call can be avoided in cases where it could become a bottleneck. Most commonly, a virtual array is backed by an actual array/span or is a single value internally, that is the same for every index. Besides those, there are many more specialized virtual arrays like the ones that provides vertex positions based on the `MVert` struct or vertex group weights. Not all attributes used by geometry nodes are stored in simple contiguous arrays. To provide uniform access to all kinds of attributes, the attribute API has to provide virtual array functionality that hides the implementation details of attributes. Before this refactor, the attribute API provided its own virtual array implementation as part of the `ReadAttribute` and `WriteAttribute` types. That resulted in unnecessary code duplication with the virtual array system. Even worse, it bound many algorithms used by geometry nodes to the specifics of the attribute API, even though they could also use different data sources (such as data from sockets, default values, later results of expressions, ...). This refactor removes the `ReadAttribute` and `WriteAttribute` types and replaces them with `GVArray` and `GVMutableArray` respectively. The `GV` stands for "generic virtual". The "generic" means that the data type contained in those virtual arrays is only known at run-time. There are the corresponding statically typed types `VArray<T>` and `VMutableArray<T>` as well. No regressions are expected from this refactor. It does come with one improvement for users. The attribute API can convert the data type on write now. This is especially useful when writing to builtin attributes like `material_index` with e.g. the Attribute Math node (which usually just writes to float attributes, while `material_index` is an integer attribute). Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
/**
* Returns an "output attribute", which is essentially a mutable virtual array with some commonly
Cleanup: spelling
2021-04-19 23:56:12 +10:00
* used convince features. The returned output attribute might be empty if requested attribute
Geometry Nodes: use virtual arrays in internal attribute api A virtual array is a data structure that is similar to a normal array in that its elements can be accessed by an index. However, a virtual array does not have to be a contiguous array internally. Instead, its elements can be layed out arbitrarily while element access happens through a virtual function call. However, the virtual array data structures are designed so that the virtual function call can be avoided in cases where it could become a bottleneck. Most commonly, a virtual array is backed by an actual array/span or is a single value internally, that is the same for every index. Besides those, there are many more specialized virtual arrays like the ones that provides vertex positions based on the `MVert` struct or vertex group weights. Not all attributes used by geometry nodes are stored in simple contiguous arrays. To provide uniform access to all kinds of attributes, the attribute API has to provide virtual array functionality that hides the implementation details of attributes. Before this refactor, the attribute API provided its own virtual array implementation as part of the `ReadAttribute` and `WriteAttribute` types. That resulted in unnecessary code duplication with the virtual array system. Even worse, it bound many algorithms used by geometry nodes to the specifics of the attribute API, even though they could also use different data sources (such as data from sockets, default values, later results of expressions, ...). This refactor removes the `ReadAttribute` and `WriteAttribute` types and replaces them with `GVArray` and `GVMutableArray` respectively. The `GV` stands for "generic virtual". The "generic" means that the data type contained in those virtual arrays is only known at run-time. There are the corresponding statically typed types `VArray<T>` and `VMutableArray<T>` as well. No regressions are expected from this refactor. It does come with one improvement for users. The attribute API can convert the data type on write now. This is especially useful when writing to builtin attributes like `material_index` with e.g. the Attribute Math node (which usually just writes to float attributes, while `material_index` is an integer attribute). Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
* cannot exist on the geometry.
*
* The included convenience features are:
* - Implicit type conversion when writing to builtin attributes.
* - If the attribute name exists already, but has a different type/domain, a temporary attribute
* is created that will overwrite the existing attribute in the end.
*/
blender::bke::OutputAttribute attribute_try_get_for_output(
const blender::StringRef attribute_name,
const AttributeDomain domain,
const CustomDataType data_type,
const void *default_value = nullptr);
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
Geometry Nodes: use virtual arrays in internal attribute api A virtual array is a data structure that is similar to a normal array in that its elements can be accessed by an index. However, a virtual array does not have to be a contiguous array internally. Instead, its elements can be layed out arbitrarily while element access happens through a virtual function call. However, the virtual array data structures are designed so that the virtual function call can be avoided in cases where it could become a bottleneck. Most commonly, a virtual array is backed by an actual array/span or is a single value internally, that is the same for every index. Besides those, there are many more specialized virtual arrays like the ones that provides vertex positions based on the `MVert` struct or vertex group weights. Not all attributes used by geometry nodes are stored in simple contiguous arrays. To provide uniform access to all kinds of attributes, the attribute API has to provide virtual array functionality that hides the implementation details of attributes. Before this refactor, the attribute API provided its own virtual array implementation as part of the `ReadAttribute` and `WriteAttribute` types. That resulted in unnecessary code duplication with the virtual array system. Even worse, it bound many algorithms used by geometry nodes to the specifics of the attribute API, even though they could also use different data sources (such as data from sockets, default values, later results of expressions, ...). This refactor removes the `ReadAttribute` and `WriteAttribute` types and replaces them with `GVArray` and `GVMutableArray` respectively. The `GV` stands for "generic virtual". The "generic" means that the data type contained in those virtual arrays is only known at run-time. There are the corresponding statically typed types `VArray<T>` and `VMutableArray<T>` as well. No regressions are expected from this refactor. It does come with one improvement for users. The attribute API can convert the data type on write now. This is especially useful when writing to builtin attributes like `material_index` with e.g. the Attribute Math node (which usually just writes to float attributes, while `material_index` is an integer attribute). Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
/* Same as attribute_try_get_for_output, but should be used when the original values in the
* attributes are not read, i.e. the attribute is used only for output. Since values are not read
* from this attribute, no default value is necessary. */
blender::bke::OutputAttribute attribute_try_get_for_output_only(
const blender::StringRef attribute_name,
Geometry Nodes: simplify supporting different input socket types for attributes This is a non-functional change. The functionality introduced in this commit is not used in master yet. It is used by nodes that are being developed in other branches though.
2020-12-09 16:20:48 +01:00
const AttributeDomain domain,
Geometry Nodes: use virtual arrays in internal attribute api A virtual array is a data structure that is similar to a normal array in that its elements can be accessed by an index. However, a virtual array does not have to be a contiguous array internally. Instead, its elements can be layed out arbitrarily while element access happens through a virtual function call. However, the virtual array data structures are designed so that the virtual function call can be avoided in cases where it could become a bottleneck. Most commonly, a virtual array is backed by an actual array/span or is a single value internally, that is the same for every index. Besides those, there are many more specialized virtual arrays like the ones that provides vertex positions based on the `MVert` struct or vertex group weights. Not all attributes used by geometry nodes are stored in simple contiguous arrays. To provide uniform access to all kinds of attributes, the attribute API has to provide virtual array functionality that hides the implementation details of attributes. Before this refactor, the attribute API provided its own virtual array implementation as part of the `ReadAttribute` and `WriteAttribute` types. That resulted in unnecessary code duplication with the virtual array system. Even worse, it bound many algorithms used by geometry nodes to the specifics of the attribute API, even though they could also use different data sources (such as data from sockets, default values, later results of expressions, ...). This refactor removes the `ReadAttribute` and `WriteAttribute` types and replaces them with `GVArray` and `GVMutableArray` respectively. The `GV` stands for "generic virtual". The "generic" means that the data type contained in those virtual arrays is only known at run-time. There are the corresponding statically typed types `VArray<T>` and `VMutableArray<T>` as well. No regressions are expected from this refactor. It does come with one improvement for users. The attribute API can convert the data type on write now. This is especially useful when writing to builtin attributes like `material_index` with e.g. the Attribute Math node (which usually just writes to float attributes, while `material_index` is an integer attribute). Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
const CustomDataType data_type);
Geometry Nodes: simplify supporting different input socket types for attributes This is a non-functional change. The functionality introduced in this commit is not used in master yet. It is used by nodes that are being developed in other branches though.
2020-12-09 16:20:48 +01:00
Geometry Nodes: use virtual arrays in internal attribute api A virtual array is a data structure that is similar to a normal array in that its elements can be accessed by an index. However, a virtual array does not have to be a contiguous array internally. Instead, its elements can be layed out arbitrarily while element access happens through a virtual function call. However, the virtual array data structures are designed so that the virtual function call can be avoided in cases where it could become a bottleneck. Most commonly, a virtual array is backed by an actual array/span or is a single value internally, that is the same for every index. Besides those, there are many more specialized virtual arrays like the ones that provides vertex positions based on the `MVert` struct or vertex group weights. Not all attributes used by geometry nodes are stored in simple contiguous arrays. To provide uniform access to all kinds of attributes, the attribute API has to provide virtual array functionality that hides the implementation details of attributes. Before this refactor, the attribute API provided its own virtual array implementation as part of the `ReadAttribute` and `WriteAttribute` types. That resulted in unnecessary code duplication with the virtual array system. Even worse, it bound many algorithms used by geometry nodes to the specifics of the attribute API, even though they could also use different data sources (such as data from sockets, default values, later results of expressions, ...). This refactor removes the `ReadAttribute` and `WriteAttribute` types and replaces them with `GVArray` and `GVMutableArray` respectively. The `GV` stands for "generic virtual". The "generic" means that the data type contained in those virtual arrays is only known at run-time. There are the corresponding statically typed types `VArray<T>` and `VMutableArray<T>` as well. No regressions are expected from this refactor. It does come with one improvement for users. The attribute API can convert the data type on write now. This is especially useful when writing to builtin attributes like `material_index` with e.g. the Attribute Math node (which usually just writes to float attributes, while `material_index` is an integer attribute). Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
/* Statically typed method corresponding to the equally named generic one. */
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
template<typename T>
Geometry Nodes: use virtual arrays in internal attribute api A virtual array is a data structure that is similar to a normal array in that its elements can be accessed by an index. However, a virtual array does not have to be a contiguous array internally. Instead, its elements can be layed out arbitrarily while element access happens through a virtual function call. However, the virtual array data structures are designed so that the virtual function call can be avoided in cases where it could become a bottleneck. Most commonly, a virtual array is backed by an actual array/span or is a single value internally, that is the same for every index. Besides those, there are many more specialized virtual arrays like the ones that provides vertex positions based on the `MVert` struct or vertex group weights. Not all attributes used by geometry nodes are stored in simple contiguous arrays. To provide uniform access to all kinds of attributes, the attribute API has to provide virtual array functionality that hides the implementation details of attributes. Before this refactor, the attribute API provided its own virtual array implementation as part of the `ReadAttribute` and `WriteAttribute` types. That resulted in unnecessary code duplication with the virtual array system. Even worse, it bound many algorithms used by geometry nodes to the specifics of the attribute API, even though they could also use different data sources (such as data from sockets, default values, later results of expressions, ...). This refactor removes the `ReadAttribute` and `WriteAttribute` types and replaces them with `GVArray` and `GVMutableArray` respectively. The `GV` stands for "generic virtual". The "generic" means that the data type contained in those virtual arrays is only known at run-time. There are the corresponding statically typed types `VArray<T>` and `VMutableArray<T>` as well. No regressions are expected from this refactor. It does come with one improvement for users. The attribute API can convert the data type on write now. This is especially useful when writing to builtin attributes like `material_index` with e.g. the Attribute Math node (which usually just writes to float attributes, while `material_index` is an integer attribute). Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
blender::bke::OutputAttribute_Typed<T> attribute_try_get_for_output(
const blender::StringRef attribute_name, const AttributeDomain domain, const T default_value)
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
{
const blender::fn::CPPType &cpp_type = blender::fn::CPPType::get<T>();
Geometry Nodes: use virtual arrays in internal attribute api A virtual array is a data structure that is similar to a normal array in that its elements can be accessed by an index. However, a virtual array does not have to be a contiguous array internally. Instead, its elements can be layed out arbitrarily while element access happens through a virtual function call. However, the virtual array data structures are designed so that the virtual function call can be avoided in cases where it could become a bottleneck. Most commonly, a virtual array is backed by an actual array/span or is a single value internally, that is the same for every index. Besides those, there are many more specialized virtual arrays like the ones that provides vertex positions based on the `MVert` struct or vertex group weights. Not all attributes used by geometry nodes are stored in simple contiguous arrays. To provide uniform access to all kinds of attributes, the attribute API has to provide virtual array functionality that hides the implementation details of attributes. Before this refactor, the attribute API provided its own virtual array implementation as part of the `ReadAttribute` and `WriteAttribute` types. That resulted in unnecessary code duplication with the virtual array system. Even worse, it bound many algorithms used by geometry nodes to the specifics of the attribute API, even though they could also use different data sources (such as data from sockets, default values, later results of expressions, ...). This refactor removes the `ReadAttribute` and `WriteAttribute` types and replaces them with `GVArray` and `GVMutableArray` respectively. The `GV` stands for "generic virtual". The "generic" means that the data type contained in those virtual arrays is only known at run-time. There are the corresponding statically typed types `VArray<T>` and `VMutableArray<T>` as well. No regressions are expected from this refactor. It does come with one improvement for users. The attribute API can convert the data type on write now. This is especially useful when writing to builtin attributes like `material_index` with e.g. the Attribute Math node (which usually just writes to float attributes, while `material_index` is an integer attribute). Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
const CustomDataType data_type = blender::bke::cpp_type_to_custom_data_type(cpp_type);
return this->attribute_try_get_for_output(attribute_name, domain, data_type, &default_value);
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
}
Geometry Nodes: use virtual arrays in internal attribute api A virtual array is a data structure that is similar to a normal array in that its elements can be accessed by an index. However, a virtual array does not have to be a contiguous array internally. Instead, its elements can be layed out arbitrarily while element access happens through a virtual function call. However, the virtual array data structures are designed so that the virtual function call can be avoided in cases where it could become a bottleneck. Most commonly, a virtual array is backed by an actual array/span or is a single value internally, that is the same for every index. Besides those, there are many more specialized virtual arrays like the ones that provides vertex positions based on the `MVert` struct or vertex group weights. Not all attributes used by geometry nodes are stored in simple contiguous arrays. To provide uniform access to all kinds of attributes, the attribute API has to provide virtual array functionality that hides the implementation details of attributes. Before this refactor, the attribute API provided its own virtual array implementation as part of the `ReadAttribute` and `WriteAttribute` types. That resulted in unnecessary code duplication with the virtual array system. Even worse, it bound many algorithms used by geometry nodes to the specifics of the attribute API, even though they could also use different data sources (such as data from sockets, default values, later results of expressions, ...). This refactor removes the `ReadAttribute` and `WriteAttribute` types and replaces them with `GVArray` and `GVMutableArray` respectively. The `GV` stands for "generic virtual". The "generic" means that the data type contained in those virtual arrays is only known at run-time. There are the corresponding statically typed types `VArray<T>` and `VMutableArray<T>` as well. No regressions are expected from this refactor. It does come with one improvement for users. The attribute API can convert the data type on write now. This is especially useful when writing to builtin attributes like `material_index` with e.g. the Attribute Math node (which usually just writes to float attributes, while `material_index` is an integer attribute). Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
/* Statically typed method corresponding to the equally named generic one. */
template<typename T>
blender::bke::OutputAttribute_Typed<T> attribute_try_get_for_output_only(
const blender::StringRef attribute_name, const AttributeDomain domain)
{
const blender::fn::CPPType &cpp_type = blender::fn::CPPType::get<T>();
const CustomDataType data_type = blender::bke::cpp_type_to_custom_data_type(cpp_type);
return this->attribute_try_get_for_output_only(attribute_name, domain, data_type);
}
Geometry Nodes: refactor internal attribute access architecture Goals: * Clarify the distinction between builtin and other attributes at the code level. * Reduce number of places that need to be modified to add more builtin attributes. * Reduce number of virtual methods that need to be implemented by e.g. `MeshComponent`. To achieve these goals, this patch implements the concept of "attribute providers". An attribute provider knows how to give access to attributes on a geometry component. Each geometry component can have multiple attribute providers, whereby each provider manages an different set of attributes. The separation of builtin and other attributes is now done at the attribute provider level. There are two types of attribute providers. One for builtin attributes and one for all others. This refactor also helps with T84297. Differential Revision: https://developer.blender.org/D10341
2021-02-09 11:24:28 +01:00
private:
virtual const blender::bke::ComponentAttributeProviders *get_attribute_providers() const;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
};
template<typename T>
inline constexpr bool is_geometry_component_v = std::is_base_of_v<GeometryComponent, T>;
/**
* A geometry set contains zero or more geometry components. There is at most one component of each
* type. Individual components might be shared between multiple geometries. Shared components are
* copied automatically when write access is requested.
*
* Copying a geometry set is a relatively cheap operation, because it does not copy the referenced
* geometry components.
*/
struct GeometrySet {
private:
using GeometryComponentPtr = blender::UserCounter<class GeometryComponent>;
blender::Map<GeometryComponentType, GeometryComponentPtr> components_;
public:
GeometryComponent &get_component_for_write(GeometryComponentType component_type);
template<typename Component> Component &get_component_for_write()
{
BLI_STATIC_ASSERT(is_geometry_component_v<Component>, "");
return static_cast<Component &>(this->get_component_for_write(Component::static_type));
}
const GeometryComponent *get_component_for_read(GeometryComponentType component_type) const;
template<typename Component> const Component *get_component_for_read() const
{
BLI_STATIC_ASSERT(is_geometry_component_v<Component>, "");
return static_cast<const Component *>(get_component_for_read(Component::static_type));
}
bool has(const GeometryComponentType component_type) const;
template<typename Component> bool has() const
{
BLI_STATIC_ASSERT(is_geometry_component_v<Component>, "");
return this->has(Component::static_type);
}
void remove(const GeometryComponentType component_type);
template<typename Component> void remove()
{
BLI_STATIC_ASSERT(is_geometry_component_v<Component>, "");
return this->remove(Component::static_type);
}
void add(const GeometryComponent &component);
Geometry Nodes: add method to get all geometry components in a set Previously, functions would have to ask for every geometry type explicitely. Using a vector is return type is fine. In practice this will probably never allocate because of the small buffer optimization in vector.
2021-02-19 12:29:37 +01:00
blender::Vector<const GeometryComponent *> get_components_for_read() const;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
void compute_boundbox_without_instances(blender::float3 *r_min, blender::float3 *r_max) const;
friend std::ostream &operator<<(std::ostream &stream, const GeometrySet &geometry_set);
friend bool operator==(const GeometrySet &a, const GeometrySet &b);
uint64_t hash() const;
Geometry Nodes: support multiple group input nodes Previously this was only supported within nested node groups. Now it is also supported for the root node group that is referenced by the modifier.
2021-03-30 12:34:05 +02:00
void clear();
Spreadsheet: support showing data of specific node Previously, the spreadsheet editor could only show data of the original and of the final evaluated object. Now it is possible to show the data at some intermediate stages too. For that the mode has to be set to "Node" in the spreadsheet editor. Furthermore, the preview of a specific node has to be activated by clicking the new icon in the header of geometry nodes. The exact ui of this feature might be refined in upcoming commits. It is already very useful for debugging node groups in it's current state though. Differential Revision: https://developer.blender.org/D10875
2021-04-08 17:35:06 +02:00
void ensure_owns_direct_data();
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
/* Utility methods for creation. */
static GeometrySet create_with_mesh(
Mesh *mesh, GeometryOwnershipType ownership = GeometryOwnershipType::Owned);
static GeometrySet create_with_pointcloud(
PointCloud *pointcloud, GeometryOwnershipType ownership = GeometryOwnershipType::Owned);
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
static GeometrySet create_with_curve(
CurveEval *curve, GeometryOwnershipType ownership = GeometryOwnershipType::Owned);
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
/* Utility methods for access. */
bool has_mesh() const;
bool has_pointcloud() const;
bool has_instances() const;
Geometry Nodes: initial support for volumes For the most part, this just adds boilerplate code for volume support in geometry nodes: * Add `VolumeComponent` next to `MeshComponent`, etc. * Support `VolumeComponent` in depsgraph object iterator. Furthermore, I added initial volume support in a few nodes: * The Object Info node outputs an object instance when the input is a volume object (that will be the same for mesh objects soonish, to avoid copies). * Support transforming a `VolumeComponent` in the Transform node. * Support the `VolumeComponent` in Join Geometry nodes, but only when just one of the inputs has a volume component for now. Right now, there is no way to create a `VolumeComponent`, because the Object Info node outputs an object instance. The `VolumeComponent` will be necessary for upcoming nodes, which will generate volumes on the fly. Viewport selection does not work correctly with `VolumeComponent`s currently. I don't know why that is. That can be figured out a bit later, once we can actually create new volumes in geometry nodes. Ref T84604. Differential Revision: https://developer.blender.org/D10147
2021-01-21 10:32:42 +01:00
bool has_volume() 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
bool has_curve() const;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
const Mesh *get_mesh_for_read() const;
const PointCloud *get_pointcloud_for_read() const;
Geometry Nodes: initial support for volumes For the most part, this just adds boilerplate code for volume support in geometry nodes: * Add `VolumeComponent` next to `MeshComponent`, etc. * Support `VolumeComponent` in depsgraph object iterator. Furthermore, I added initial volume support in a few nodes: * The Object Info node outputs an object instance when the input is a volume object (that will be the same for mesh objects soonish, to avoid copies). * Support transforming a `VolumeComponent` in the Transform node. * Support the `VolumeComponent` in Join Geometry nodes, but only when just one of the inputs has a volume component for now. Right now, there is no way to create a `VolumeComponent`, because the Object Info node outputs an object instance. The `VolumeComponent` will be necessary for upcoming nodes, which will generate volumes on the fly. Viewport selection does not work correctly with `VolumeComponent`s currently. I don't know why that is. That can be figured out a bit later, once we can actually create new volumes in geometry nodes. Ref T84604. Differential Revision: https://developer.blender.org/D10147
2021-01-21 10:32:42 +01:00
const Volume *get_volume_for_read() 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
const CurveEval *get_curve_for_read() const;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
Mesh *get_mesh_for_write();
PointCloud *get_pointcloud_for_write();
Geometry Nodes: initial support for volumes For the most part, this just adds boilerplate code for volume support in geometry nodes: * Add `VolumeComponent` next to `MeshComponent`, etc. * Support `VolumeComponent` in depsgraph object iterator. Furthermore, I added initial volume support in a few nodes: * The Object Info node outputs an object instance when the input is a volume object (that will be the same for mesh objects soonish, to avoid copies). * Support transforming a `VolumeComponent` in the Transform node. * Support the `VolumeComponent` in Join Geometry nodes, but only when just one of the inputs has a volume component for now. Right now, there is no way to create a `VolumeComponent`, because the Object Info node outputs an object instance. The `VolumeComponent` will be necessary for upcoming nodes, which will generate volumes on the fly. Viewport selection does not work correctly with `VolumeComponent`s currently. I don't know why that is. That can be figured out a bit later, once we can actually create new volumes in geometry nodes. Ref T84604. Differential Revision: https://developer.blender.org/D10147
2021-01-21 10:32:42 +01:00
Volume *get_volume_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
CurveEval *get_curve_for_write();
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
/* Utility methods for replacement. */
void replace_mesh(Mesh *mesh, GeometryOwnershipType ownership = GeometryOwnershipType::Owned);
void replace_pointcloud(PointCloud *pointcloud,
GeometryOwnershipType ownership = GeometryOwnershipType::Owned);
Cleanup: Replace modifyVolume with modifyGeometrySet This allows us to remove a callback from the modifier type info struct. In the future the these modifiers might just be replaced by nodes internally anyway, but in the meantime it's nice to unify the handling of evaluated geometry a bit. Differential Revision: https://developer.blender.org/D11080
2021-04-26 14:42:03 -05:00
void replace_volume(Volume *volume,
GeometryOwnershipType ownership = GeometryOwnershipType::Owned);
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
void replace_curve(CurveEval *curve,
GeometryOwnershipType ownership = GeometryOwnershipType::Owned);
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
};
/** A geometry component that can store a mesh. */
class MeshComponent : public GeometryComponent {
private:
Mesh *mesh_ = nullptr;
GeometryOwnershipType ownership_ = GeometryOwnershipType::Owned;
/* Due to historical design choices, vertex group data is stored in the mesh, but the vertex
* group names are stored on an object. Since we don't have an object here, we copy over the
* names into this map. */
blender::Map<std::string, int> vertex_group_names_;
public:
MeshComponent();
~MeshComponent();
GeometryComponent *copy() const override;
void clear();
bool has_mesh() const;
void replace(Mesh *mesh, GeometryOwnershipType ownership = GeometryOwnershipType::Owned);
Fix T85155: Vertex groups from object don't transfer to next nodes modifier Because the the vertex group name-to-index map is stored in the object rather than object data, the object info node has to replace the map when it replaces the mesh component on the geometry set with mesh data from another object. This normally works fine as a way to use the vertex groups from the input mesh, but when passing this mesh to the next modifier, the entire mesh component was replaced, removing the vertex group name map. This commit adds a function to replace only the mesh data in mesh component, uses it in the modifier code, and updates the relevant comments. Note that the fact that vertex group names are stored in object data is a legacy design decision that should be reevaluated at some point. Differential Revision: https://developer.blender.org/D10256
2021-02-02 09:20:54 -06:00
void replace_mesh_but_keep_vertex_group_names(
Mesh *mesh, GeometryOwnershipType ownership = GeometryOwnershipType::Owned);
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
Mesh *release();
void copy_vertex_group_names_from_object(const struct Object &object);
Geometry Nodes: refactor internal attribute access architecture Goals: * Clarify the distinction between builtin and other attributes at the code level. * Reduce number of places that need to be modified to add more builtin attributes. * Reduce number of virtual methods that need to be implemented by e.g. `MeshComponent`. To achieve these goals, this patch implements the concept of "attribute providers". An attribute provider knows how to give access to attributes on a geometry component. Each geometry component can have multiple attribute providers, whereby each provider manages an different set of attributes. The separation of builtin and other attributes is now done at the attribute provider level. There are two types of attribute providers. One for builtin attributes and one for all others. This refactor also helps with T84297. Differential Revision: https://developer.blender.org/D10341
2021-02-09 11:24:28 +01:00
const blender::Map<std::string, int> &vertex_group_names() const;
blender::Map<std::string, int> &vertex_group_names();
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
const Mesh *get_for_read() const;
Mesh *get_for_write();
int attribute_domain_size(const AttributeDomain domain) const final;
Geometry Nodes: use virtual arrays in internal attribute api A virtual array is a data structure that is similar to a normal array in that its elements can be accessed by an index. However, a virtual array does not have to be a contiguous array internally. Instead, its elements can be layed out arbitrarily while element access happens through a virtual function call. However, the virtual array data structures are designed so that the virtual function call can be avoided in cases where it could become a bottleneck. Most commonly, a virtual array is backed by an actual array/span or is a single value internally, that is the same for every index. Besides those, there are many more specialized virtual arrays like the ones that provides vertex positions based on the `MVert` struct or vertex group weights. Not all attributes used by geometry nodes are stored in simple contiguous arrays. To provide uniform access to all kinds of attributes, the attribute API has to provide virtual array functionality that hides the implementation details of attributes. Before this refactor, the attribute API provided its own virtual array implementation as part of the `ReadAttribute` and `WriteAttribute` types. That resulted in unnecessary code duplication with the virtual array system. Even worse, it bound many algorithms used by geometry nodes to the specifics of the attribute API, even though they could also use different data sources (such as data from sockets, default values, later results of expressions, ...). This refactor removes the `ReadAttribute` and `WriteAttribute` types and replaces them with `GVArray` and `GVMutableArray` respectively. The `GV` stands for "generic virtual". The "generic" means that the data type contained in those virtual arrays is only known at run-time. There are the corresponding statically typed types `VArray<T>` and `VMutableArray<T>` as well. No regressions are expected from this refactor. It does come with one improvement for users. The attribute API can convert the data type on write now. This is especially useful when writing to builtin attributes like `material_index` with e.g. the Attribute Math node (which usually just writes to float attributes, while `material_index` is an integer attribute). Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
std::unique_ptr<blender::fn::GVArray> attribute_try_adapt_domain(
std::unique_ptr<blender::fn::GVArray> varray,
const AttributeDomain from_domain,
const AttributeDomain to_domain) const final;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
bool is_empty() const final;
Spreadsheet: support showing data of specific node Previously, the spreadsheet editor could only show data of the original and of the final evaluated object. Now it is possible to show the data at some intermediate stages too. For that the mode has to be set to "Node" in the spreadsheet editor. Furthermore, the preview of a specific node has to be activated by clicking the new icon in the header of geometry nodes. The exact ui of this feature might be refined in upcoming commits. It is already very useful for debugging node groups in it's current state though. Differential Revision: https://developer.blender.org/D10875
2021-04-08 17:35:06 +02:00
bool owns_direct_data() const override;
void ensure_owns_direct_data() override;
Geometry Nodes: move geometry component type enum to C This allows us to use it in rna for the spreadsheet editor.
2021-03-10 11:53:17 +01:00
static constexpr inline GeometryComponentType static_type = GEO_COMPONENT_TYPE_MESH;
Geometry Nodes: refactor internal attribute access architecture Goals: * Clarify the distinction between builtin and other attributes at the code level. * Reduce number of places that need to be modified to add more builtin attributes. * Reduce number of virtual methods that need to be implemented by e.g. `MeshComponent`. To achieve these goals, this patch implements the concept of "attribute providers". An attribute provider knows how to give access to attributes on a geometry component. Each geometry component can have multiple attribute providers, whereby each provider manages an different set of attributes. The separation of builtin and other attributes is now done at the attribute provider level. There are two types of attribute providers. One for builtin attributes and one for all others. This refactor also helps with T84297. Differential Revision: https://developer.blender.org/D10341
2021-02-09 11:24:28 +01:00
private:
const blender::bke::ComponentAttributeProviders *get_attribute_providers() const final;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
};
/** A geometry component that stores a point cloud. */
class PointCloudComponent : public GeometryComponent {
private:
PointCloud *pointcloud_ = nullptr;
GeometryOwnershipType ownership_ = GeometryOwnershipType::Owned;
public:
PointCloudComponent();
~PointCloudComponent();
GeometryComponent *copy() const override;
void clear();
bool has_pointcloud() const;
void replace(PointCloud *pointcloud,
GeometryOwnershipType ownership = GeometryOwnershipType::Owned);
PointCloud *release();
const PointCloud *get_for_read() const;
PointCloud *get_for_write();
int attribute_domain_size(const AttributeDomain domain) const final;
bool is_empty() const final;
Spreadsheet: support showing data of specific node Previously, the spreadsheet editor could only show data of the original and of the final evaluated object. Now it is possible to show the data at some intermediate stages too. For that the mode has to be set to "Node" in the spreadsheet editor. Furthermore, the preview of a specific node has to be activated by clicking the new icon in the header of geometry nodes. The exact ui of this feature might be refined in upcoming commits. It is already very useful for debugging node groups in it's current state though. Differential Revision: https://developer.blender.org/D10875
2021-04-08 17:35:06 +02:00
bool owns_direct_data() const override;
void ensure_owns_direct_data() override;
Geometry Nodes: move geometry component type enum to C This allows us to use it in rna for the spreadsheet editor.
2021-03-10 11:53:17 +01:00
static constexpr inline GeometryComponentType static_type = GEO_COMPONENT_TYPE_POINT_CLOUD;
Geometry Nodes: refactor internal attribute access architecture Goals: * Clarify the distinction between builtin and other attributes at the code level. * Reduce number of places that need to be modified to add more builtin attributes. * Reduce number of virtual methods that need to be implemented by e.g. `MeshComponent`. To achieve these goals, this patch implements the concept of "attribute providers". An attribute provider knows how to give access to attributes on a geometry component. Each geometry component can have multiple attribute providers, whereby each provider manages an different set of attributes. The separation of builtin and other attributes is now done at the attribute provider level. There are two types of attribute providers. One for builtin attributes and one for all others. This refactor also helps with T84297. Differential Revision: https://developer.blender.org/D10341
2021-02-09 11:24:28 +01:00
private:
const blender::bke::ComponentAttributeProviders *get_attribute_providers() const final;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
};
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
/** A geometry component that stores curve data, in other words, a group of splines. */
class CurveComponent : public GeometryComponent {
private:
CurveEval *curve_ = nullptr;
GeometryOwnershipType ownership_ = GeometryOwnershipType::Owned;
Geometry Nodes: Draw curve data in the viewport This patch adds relatively small changes to the curve draw cache implementation in order to draw the curve data in the viewport. The dependency graph iterator is also modified so that it iterates over the curve geometry component, which is presented to users as `Curve` data with a pointer to the `CurveEval` The idea with the spline data type in geometry nodes is that curve data itself is only the control points, and any evaluated data with faces is a mesh. That is mostly expected elsewhere in Blender anyway. This means it's only necessary to implement wire edge drawing of `CurveEval` data. Adding a `CurveEval` pointer to `Curve` is in line with changes I'd like to make in the future like using `CurveEval` in more places such as edit mode. An alternate solution involves converting the curve wire data to a mesh, however, that requires copying all of the data, and since avoiding it is rather simple and is in-line with future plans anyway, I think doing it this way is better. Differential Revision: https://developer.blender.org/D11351
2021-05-27 10:08:40 -04:00
/**
* Curve data necessary to hold the draw cache for rendering, consistent over multiple redraws.
* This is necessary because Blender assumes that objects evaluate to an object data type, and
* we use #CurveEval rather than #Curve here. It also allows us to mostly reuse the same
* batch cache implementation.
*/
mutable Curve *curve_for_render_ = nullptr;
mutable std::mutex curve_for_render_mutex_;
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
public:
CurveComponent();
~CurveComponent();
GeometryComponent *copy() const override;
void clear();
bool has_curve() const;
void replace(CurveEval *curve, GeometryOwnershipType ownership = GeometryOwnershipType::Owned);
CurveEval *release();
const CurveEval *get_for_read() const;
CurveEval *get_for_write();
int attribute_domain_size(const AttributeDomain domain) const final;
Geometry Nodes: Support interpolation between curve domains This commit adds interpolation from the point domain to the spline domain and the other way around. Before this, spline domain attributes were basically useless, but now they are quite helpful as a way to use a shared value in a contiguous group of points. I implementented a special virtual array for the spline to points conversion, so that conversion should be close to the ideal performance level, but there are a few ways we could optimize the point to spline conversion in the future: - Use a function virtual array to mix the point values for each spline on demand. - Implement a special case for when the input virtual array is one of the virtual arrays from the spline point attributes. In other words, decrease curve attribute access overhead. Differential Revision: https://developer.blender.org/D11376
2021-05-26 22:14:59 -04:00
std::unique_ptr<blender::fn::GVArray> attribute_try_adapt_domain(
std::unique_ptr<blender::fn::GVArray> varray,
const AttributeDomain from_domain,
const AttributeDomain to_domain) const final;
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
bool is_empty() const final;
bool owns_direct_data() const override;
void ensure_owns_direct_data() override;
Geometry Nodes: Draw curve data in the viewport This patch adds relatively small changes to the curve draw cache implementation in order to draw the curve data in the viewport. The dependency graph iterator is also modified so that it iterates over the curve geometry component, which is presented to users as `Curve` data with a pointer to the `CurveEval` The idea with the spline data type in geometry nodes is that curve data itself is only the control points, and any evaluated data with faces is a mesh. That is mostly expected elsewhere in Blender anyway. This means it's only necessary to implement wire edge drawing of `CurveEval` data. Adding a `CurveEval` pointer to `Curve` is in line with changes I'd like to make in the future like using `CurveEval` in more places such as edit mode. An alternate solution involves converting the curve wire data to a mesh, however, that requires copying all of the data, and since avoiding it is rather simple and is in-line with future plans anyway, I think doing it this way is better. Differential Revision: https://developer.blender.org/D11351
2021-05-27 10:08:40 -04:00
const Curve *get_curve_for_render() 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
static constexpr inline GeometryComponentType static_type = GEO_COMPONENT_TYPE_CURVE;
private:
const blender::bke::ComponentAttributeProviders *get_attribute_providers() const final;
};
Geometry Nodes: refactor instances component The main goal of this refactor is to not store Object/Collection pointers for every individual instance. Instead instances now store a handle for the referenced data. The actual Object/Collection pointers are stored in a new `InstanceReference` class. This refactor also allows for some better optimizations further down the line, because one does not have to search through all instances anymore to find what data is instanced. Furthermore, this refactor makes it easier to support instancing `GeometrySet` or any other data that has to be owned by the `InstancesComponent`. Differential Revision: https://developer.blender.org/D11125
2021-05-04 10:16:24 +02:00
class InstanceReference {
public:
enum class Type {
/**
* An empty instance. This allows an `InstanceReference` to be default constructed without
* being in an invalid state. There might also be other use cases that we haven't explored much
* yet (such as changing the instance later on, and "disabling" some instances).
*/
None,
Object,
Collection,
};
private:
Type type_ = Type::None;
/** Depending on the type this is either null, an Object or Collection pointer. */
void *data_ = nullptr;
public:
InstanceReference() = default;
InstanceReference(Object &object) : type_(Type::Object), data_(&object)
{
}
InstanceReference(Collection &collection) : type_(Type::Collection), data_(&collection)
{
}
Type type() const
{
return type_;
}
Object &object() const
{
BLI_assert(type_ == Type::Object);
return *(Object *)data_;
}
Collection &collection() const
{
BLI_assert(type_ == Type::Collection);
return *(Collection *)data_;
}
uint64_t hash() const
{
return blender::get_default_hash(data_);
}
friend bool operator==(const InstanceReference &a, const InstanceReference &b)
{
return a.data_ == b.data_;
}
};
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
/** A geometry component that stores instances. */
class InstancesComponent : public GeometryComponent {
private:
Geometry Nodes: refactor instances component The main goal of this refactor is to not store Object/Collection pointers for every individual instance. Instead instances now store a handle for the referenced data. The actual Object/Collection pointers are stored in a new `InstanceReference` class. This refactor also allows for some better optimizations further down the line, because one does not have to search through all instances anymore to find what data is instanced. Furthermore, this refactor makes it easier to support instancing `GeometrySet` or any other data that has to be owned by the `InstancesComponent`. Differential Revision: https://developer.blender.org/D11125
2021-05-04 10:16:24 +02:00
/**
* Indexed set containing information about the data that is instanced.
* Actual instances store an index ("handle") into this set.
*/
blender::VectorSet<InstanceReference> references_;
/** Index into `references_`. Determines what data is instanced. */
blender::Vector<int> instance_reference_handles_;
/** Transformation of the instances. */
blender::Vector<blender::float4x4> instance_transforms_;
/**
* IDs of the instances. They are used for consistency over multiple frames for things like
* motion blur.
*/
blender::Vector<int> instance_ids_;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
Fix T84899: instance ids are not unique in common cases Ids stored in the `id` attribute cannot be assumed to be unique. While they might be unique in some cases, this is not something that can be guaranteed in general. For some use cases (e.g. generating "stable randomness" on points) uniqueness is not important. To support features like motion blur, unique ids are important though. This patch implements a simple algorithm that turns non-unique ids into unique ones. It might fail to do so under very unlikely circumstances, in which it returns non-unique ids instead of possibly going into an endless loop. Here are some requirements I set for the algorithm: * Ids that are unique already, must not be changed. * The same input should generate the same output. * Handle cases when all ids are different and when all ids are the same equally well (in expected linear time). * Small changes in the input id array should ideally only have a small impact on the output id array. The reported bug happened because cycles found multiple objects with the same id and thought that it was a single object that moved on every check. Differential Revision: https://developer.blender.org/D10402
2021-02-12 17:41:28 +01:00
/* These almost unique ids are generated based on `ids_`, which might not contain unique ids at
* all. They are *almost* unique, because under certain very unlikely circumstances, they are not
* unique. Code using these ids should not crash when they are not unique but can generally
* expect them to be unique. */
mutable std::mutex almost_unique_ids_mutex_;
mutable blender::Array<int> almost_unique_ids_;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
public:
InstancesComponent();
~InstancesComponent() = default;
GeometryComponent *copy() const override;
void clear();
Geometry Nodes: refactor instances component The main goal of this refactor is to not store Object/Collection pointers for every individual instance. Instead instances now store a handle for the referenced data. The actual Object/Collection pointers are stored in a new `InstanceReference` class. This refactor also allows for some better optimizations further down the line, because one does not have to search through all instances anymore to find what data is instanced. Furthermore, this refactor makes it easier to support instancing `GeometrySet` or any other data that has to be owned by the `InstancesComponent`. Differential Revision: https://developer.blender.org/D11125
2021-05-04 10:16:24 +02:00
void reserve(int min_capacity);
Geometry Nodes: Improve point instance node performance This commit uses two changes to improve the performance of the point instance node. **Prevent Reallocations** At 64 bytes, the transform matrix for every instance is rather large, so reallocating the vector as it grows can become a performance bottle- neck. This commit reserves memory for the instances that will be added to prevent unecessary reallocations as the instance vector grows. In a test with 4 million instances of 3 objects in a collection, the node was about 40% faster, from 370ms to 270ms for the node. **Parallelization** Currently the instances are added by appending to a vector. By changing this slightly to fill indices instead, we can parallelize the operation so that multiple threads can fill data at the same time. Tested on a Ryzen 3700x, this reduced the runtime from the above 270ms to 44ms average, bringing the total speedup to ~8x. Note that displaying the instances in the viewport is still much slower than the calculations in node, this change doesn't affect that.
2021-05-08 23:57:36 -05:00
void resize(int capacity);
Geometry Nodes: refactor instances component The main goal of this refactor is to not store Object/Collection pointers for every individual instance. Instead instances now store a handle for the referenced data. The actual Object/Collection pointers are stored in a new `InstanceReference` class. This refactor also allows for some better optimizations further down the line, because one does not have to search through all instances anymore to find what data is instanced. Furthermore, this refactor makes it easier to support instancing `GeometrySet` or any other data that has to be owned by the `InstancesComponent`. Differential Revision: https://developer.blender.org/D11125
2021-05-04 10:16:24 +02:00
int add_reference(InstanceReference reference);
void add_instance(int instance_handle, const blender::float4x4 &transform, const int id = -1);
blender::Span<InstanceReference> references() const;
blender::Span<int> instance_reference_handles() const;
Geometry Nodes: Improve point instance node performance This commit uses two changes to improve the performance of the point instance node. **Prevent Reallocations** At 64 bytes, the transform matrix for every instance is rather large, so reallocating the vector as it grows can become a performance bottle- neck. This commit reserves memory for the instances that will be added to prevent unecessary reallocations as the instance vector grows. In a test with 4 million instances of 3 objects in a collection, the node was about 40% faster, from 370ms to 270ms for the node. **Parallelization** Currently the instances are added by appending to a vector. By changing this slightly to fill indices instead, we can parallelize the operation so that multiple threads can fill data at the same time. Tested on a Ryzen 3700x, this reduced the runtime from the above 270ms to 44ms average, bringing the total speedup to ~8x. Note that displaying the instances in the viewport is still much slower than the calculations in node, this change doesn't affect that.
2021-05-08 23:57:36 -05:00
blender::MutableSpan<int> instance_reference_handles();
Geometry Nodes: refactor instances component The main goal of this refactor is to not store Object/Collection pointers for every individual instance. Instead instances now store a handle for the referenced data. The actual Object/Collection pointers are stored in a new `InstanceReference` class. This refactor also allows for some better optimizations further down the line, because one does not have to search through all instances anymore to find what data is instanced. Furthermore, this refactor makes it easier to support instancing `GeometrySet` or any other data that has to be owned by the `InstancesComponent`. Differential Revision: https://developer.blender.org/D11125
2021-05-04 10:16:24 +02:00
blender::MutableSpan<blender::float4x4> instance_transforms();
blender::Span<blender::float4x4> instance_transforms() const;
blender::MutableSpan<int> instance_ids();
blender::Span<int> instance_ids() const;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
int instances_amount() const;
Fix T84899: instance ids are not unique in common cases Ids stored in the `id` attribute cannot be assumed to be unique. While they might be unique in some cases, this is not something that can be guaranteed in general. For some use cases (e.g. generating "stable randomness" on points) uniqueness is not important. To support features like motion blur, unique ids are important though. This patch implements a simple algorithm that turns non-unique ids into unique ones. It might fail to do so under very unlikely circumstances, in which it returns non-unique ids instead of possibly going into an endless loop. Here are some requirements I set for the algorithm: * Ids that are unique already, must not be changed. * The same input should generate the same output. * Handle cases when all ids are different and when all ids are the same equally well (in expected linear time). * Small changes in the input id array should ideally only have a small impact on the output id array. The reported bug happened because cycles found multiple objects with the same id and thought that it was a single object that moved on every check. Differential Revision: https://developer.blender.org/D10402
2021-02-12 17:41:28 +01:00
blender::Span<int> almost_unique_ids() const;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
bool is_empty() const final;
Spreadsheet: support showing data of specific node Previously, the spreadsheet editor could only show data of the original and of the final evaluated object. Now it is possible to show the data at some intermediate stages too. For that the mode has to be set to "Node" in the spreadsheet editor. Furthermore, the preview of a specific node has to be activated by clicking the new icon in the header of geometry nodes. The exact ui of this feature might be refined in upcoming commits. It is already very useful for debugging node groups in it's current state though. Differential Revision: https://developer.blender.org/D10875
2021-04-08 17:35:06 +02:00
bool owns_direct_data() const override;
void ensure_owns_direct_data() override;
Geometry Nodes: move geometry component type enum to C This allows us to use it in rna for the spreadsheet editor.
2021-03-10 11:53:17 +01:00
static constexpr inline GeometryComponentType static_type = GEO_COMPONENT_TYPE_INSTANCES;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
};
Geometry Nodes: initial support for volumes For the most part, this just adds boilerplate code for volume support in geometry nodes: * Add `VolumeComponent` next to `MeshComponent`, etc. * Support `VolumeComponent` in depsgraph object iterator. Furthermore, I added initial volume support in a few nodes: * The Object Info node outputs an object instance when the input is a volume object (that will be the same for mesh objects soonish, to avoid copies). * Support transforming a `VolumeComponent` in the Transform node. * Support the `VolumeComponent` in Join Geometry nodes, but only when just one of the inputs has a volume component for now. Right now, there is no way to create a `VolumeComponent`, because the Object Info node outputs an object instance. The `VolumeComponent` will be necessary for upcoming nodes, which will generate volumes on the fly. Viewport selection does not work correctly with `VolumeComponent`s currently. I don't know why that is. That can be figured out a bit later, once we can actually create new volumes in geometry nodes. Ref T84604. Differential Revision: https://developer.blender.org/D10147
2021-01-21 10:32:42 +01:00
/** A geometry component that stores volume grids. */
class VolumeComponent : public GeometryComponent {
private:
Volume *volume_ = nullptr;
GeometryOwnershipType ownership_ = GeometryOwnershipType::Owned;
public:
VolumeComponent();
~VolumeComponent();
GeometryComponent *copy() const override;
void clear();
bool has_volume() const;
void replace(Volume *volume, GeometryOwnershipType ownership = GeometryOwnershipType::Owned);
Volume *release();
const Volume *get_for_read() const;
Volume *get_for_write();
Spreadsheet: support showing data of specific node Previously, the spreadsheet editor could only show data of the original and of the final evaluated object. Now it is possible to show the data at some intermediate stages too. For that the mode has to be set to "Node" in the spreadsheet editor. Furthermore, the preview of a specific node has to be activated by clicking the new icon in the header of geometry nodes. The exact ui of this feature might be refined in upcoming commits. It is already very useful for debugging node groups in it's current state though. Differential Revision: https://developer.blender.org/D10875
2021-04-08 17:35:06 +02:00
bool owns_direct_data() const override;
void ensure_owns_direct_data() override;
Geometry Nodes: move geometry component type enum to C This allows us to use it in rna for the spreadsheet editor.
2021-03-10 11:53:17 +01:00
static constexpr inline GeometryComponentType static_type = GEO_COMPONENT_TYPE_VOLUME;
Geometry Nodes: initial support for volumes For the most part, this just adds boilerplate code for volume support in geometry nodes: * Add `VolumeComponent` next to `MeshComponent`, etc. * Support `VolumeComponent` in depsgraph object iterator. Furthermore, I added initial volume support in a few nodes: * The Object Info node outputs an object instance when the input is a volume object (that will be the same for mesh objects soonish, to avoid copies). * Support transforming a `VolumeComponent` in the Transform node. * Support the `VolumeComponent` in Join Geometry nodes, but only when just one of the inputs has a volume component for now. Right now, there is no way to create a `VolumeComponent`, because the Object Info node outputs an object instance. The `VolumeComponent` will be necessary for upcoming nodes, which will generate volumes on the fly. Viewport selection does not work correctly with `VolumeComponent`s currently. I don't know why that is. That can be figured out a bit later, once we can actually create new volumes in geometry nodes. Ref T84604. Differential Revision: https://developer.blender.org/D10147
2021-01-21 10:32:42 +01:00
};
Copy Permalink