Files
test2/source/blender/nodes/geometry/node_geometry_util.hh

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

119 lines
4.2 KiB
C++
Raw Normal View History

/* SPDX-License-Identifier: GPL-2.0-or-later */
#pragma once
#include <string.h>
#include "BLI_math_matrix_types.hh"
#include "BLI_math_vector_types.hh"
#include "BLI_utildefines.h"
#include "MEM_guardedalloc.h"
#include "DNA_node_types.h"
#include "BKE_node.h"
#include "BLT_translation.h"
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 "NOD_geometry.h"
#include "NOD_geometry_exec.hh"
#include "NOD_socket_declarations.hh"
#include "NOD_socket_declarations_geometry.hh"
#include "RNA_access.h"
#include "node_geometry_register.hh"
#include "node_util.h"
struct BVHTreeFromMesh;
void geo_node_type_base(struct bNodeType *ntype, int type, const char *name, short nclass);
bool geo_node_poll_default(const struct bNodeType *ntype,
const struct bNodeTree *ntree,
const char **r_disabled_hint);
namespace blender::nodes {
void transform_mesh(Mesh &mesh,
const float3 translation,
const float3 rotation,
const float3 scale);
void transform_geometry_set(GeoNodeExecParams &params,
GeometrySet &geometry,
const float4x4 &transform,
const Depsgraph &depsgraph);
Mesh *create_line_mesh(const float3 start, const float3 delta, int count);
Geometry Nodes: output uv map from primitive nodes as anonymous attributes This is essentially a left-over from the initial transition to fields where this was forgotten. The mesh primitive nodes used to create a named uv map attribute with a hard-coded name. The standard way to deal with that in geometry nodes now is to output the attribute as a socket instead. The user can then decide to store it as a named attribute or not. The benefits of not always storing the named attribute in the node are: * Improved performance and lower memory usage when the uv map is not used. * It's more obvious that there actually is a uv map. * The hard-coded name was inconsistent. The versioning code inserts a new Store Named Attribute node that stores the uv map immediatly. In many cases, users can probably just remove this node without affecting their final result, but we can't detect that. There is one behavior change which is that the stored uv map will be a 3d vector instead of a 2d vector which is what the nodes originally created. We could store the uv map as 2d vector inthe Store Named Attribute node, but that has the problem that older Blender versions don't support this and would crash immediately. Users can just change this to 2d vector manually if they don't care about forward compatibility. There is a plan to support 2d vectors more natively in geometry nodes: T92765. This change breaks forward compatibility in the case when the uv map was used. Differential Revision: https://developer.blender.org/D16637
2022-12-14 18:05:31 +01:00
Mesh *create_grid_mesh(
int verts_x, int verts_y, float size_x, float size_y, const AttributeIDRef &uv_map_id);
struct ConeAttributeOutputs {
AutoAnonymousAttributeID top_id;
AutoAnonymousAttributeID bottom_id;
AutoAnonymousAttributeID side_id;
AutoAnonymousAttributeID uv_map_id;
};
Mesh *create_cylinder_or_cone_mesh(float radius_top,
float radius_bottom,
float depth,
int circle_segments,
int side_segments,
int fill_segments,
GeometryNodeMeshCircleFillType fill_type,
ConeAttributeOutputs &attribute_outputs);
/**
* Copies the point domain attributes from `in_component` that are in the mask to `out_component`.
*/
void copy_point_attributes_based_on_mask(const GeometryComponent &in_component,
GeometryComponent &result_component,
Span<bool> masks,
bool invert);
/**
* Returns the parts of the geometry that are on the selection for the given domain. If the domain
* is not applicable for the component, e.g. face domain for point cloud, nothing happens to that
* component. If no component can work with the domain, then `error_message` is set to true.
*/
void separate_geometry(GeometrySet &geometry_set,
eAttrDomain domain,
GeometryNodeDeleteGeometryMode mode,
const Field<bool> &selection_field,
const AnonymousAttributePropagationInfo &propagation_info,
bool &r_is_error);
void get_closest_in_bvhtree(BVHTreeFromMesh &tree_data,
const VArray<float3> &positions,
const IndexMask mask,
const MutableSpan<int> r_indices,
const MutableSpan<float> r_distances_sq,
const MutableSpan<float3> r_positions);
Geometry Nodes: Curve and mesh topology access nodes This patch contains an initial set of nodes to access basic mesh topology information, as explored in T100020. The nodes allow six direct topology mappings for meshes: - **Corner -> Face** The face a corner is in, the index in the face - **Vertex -> Edge** Choose an edge attached to the vertex - **Vertex -> Corner** Choose a corner attached to the vertex - **Corner -> Edge** The next and previous edge at each face corner - **Corner -> Vertex** The vertex associated with a corner - **Corner -> Corner** Offset a corner index within a face And two new topology mappings for curves: - **Curve -> Points** Choose a point within a curve - **Point -> Curve** The curve a point is in, the index in the curve The idea is that some of the 16 possible mesh mappings are more important, and that this is a useful set of nodes to start exploring this area. For mappings with an arbitrary number of connections, we must sort them and use an index to choose a single element, because geometry nodes does not support list fields. Note that the sort index has repeating behavior as it goes over the "Total" number of connections, and negative sort indices choose from the end. Currently which of the "start" elements is used is determined by the field context, so the "Field at Index" and "Interpolate Domain" nodes will be quite important. Also, currently the "Sort Index" inputs are clamped to the number of connections. One important feature that isn't implemented here is using the winding order for the output elements. This can be a separate mode for some of these nodes. It will be optional because of the performance impact. There are several todos for separate commits after this: - Rename "Control Point Neighbors" to be consistent with this naming - Version away the "Vertex Neighbors" node which is fully redundant now - Implement a special case for when no weights are used for performance - De-duplicating some of the sorting logic between the nodes - Improve performance and memory use of topology mappings - Look into caching some of the mappings on meshes Differential Revision: https://developer.blender.org/D16029
2022-09-28 14:38:27 -05:00
int apply_offset_in_cyclic_range(IndexRange range, int start_index, int offset);
std::optional<eCustomDataType> node_data_type_to_custom_data_type(eNodeSocketDatatype type);
std::optional<eCustomDataType> node_socket_to_custom_data_type(const bNodeSocket &socket);
Geometry Nodes: Curve and mesh topology access nodes This patch contains an initial set of nodes to access basic mesh topology information, as explored in T100020. The nodes allow six direct topology mappings for meshes: - **Corner -> Face** The face a corner is in, the index in the face - **Vertex -> Edge** Choose an edge attached to the vertex - **Vertex -> Corner** Choose a corner attached to the vertex - **Corner -> Edge** The next and previous edge at each face corner - **Corner -> Vertex** The vertex associated with a corner - **Corner -> Corner** Offset a corner index within a face And two new topology mappings for curves: - **Curve -> Points** Choose a point within a curve - **Point -> Curve** The curve a point is in, the index in the curve The idea is that some of the 16 possible mesh mappings are more important, and that this is a useful set of nodes to start exploring this area. For mappings with an arbitrary number of connections, we must sort them and use an index to choose a single element, because geometry nodes does not support list fields. Note that the sort index has repeating behavior as it goes over the "Total" number of connections, and negative sort indices choose from the end. Currently which of the "start" elements is used is determined by the field context, so the "Field at Index" and "Interpolate Domain" nodes will be quite important. Also, currently the "Sort Index" inputs are clamped to the number of connections. One important feature that isn't implemented here is using the winding order for the output elements. This can be a separate mode for some of these nodes. It will be optional because of the performance impact. There are several todos for separate commits after this: - Rename "Control Point Neighbors" to be consistent with this naming - Version away the "Vertex Neighbors" node which is fully redundant now - Implement a special case for when no weights are used for performance - De-duplicating some of the sorting logic between the nodes - Improve performance and memory use of topology mappings - Look into caching some of the mappings on meshes Differential Revision: https://developer.blender.org/D16029
2022-09-28 14:38:27 -05:00
class FieldAtIndexInput final : public bke::GeometryFieldInput {
private:
Field<int> index_field_;
GField value_field_;
eAttrDomain value_field_domain_;
public:
FieldAtIndexInput(Field<int> index_field, GField value_field, eAttrDomain value_field_domain);
GVArray get_varray_for_context(const bke::GeometryFieldContext &context,
const IndexMask mask) const final;
std::optional<eAttrDomain> preferred_domain(const GeometryComponent & /*component*/) const final
{
return value_field_domain_;
}
};
} // namespace blender::nodes