Files
test2/source/blender/blenkernel/intern/pointcloud.cc

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

418 lines
13 KiB
C++
Raw Normal View History

/* SPDX-FileCopyrightText: 2023 Blender Authors
*
* SPDX-License-Identifier: GPL-2.0-or-later */
/** \file
* \ingroup bke
*/
#include <optional>
#include "MEM_guardedalloc.h"
#include "DNA_defaults.h"
#include "DNA_material_types.h"
#include "DNA_object_types.h"
#include "DNA_pointcloud_types.h"
#include "BLI_bounds.hh"
#include "BLI_index_range.hh"
Geometry: Cache bounds min and max, share between data-blocks Bounding box calculation can be a large in some situations, especially instancing. This patch caches the min and max of the bounding box in runtime data of meshes, point clouds, and curves, implementing part of T96968. Bounds are now calculated lazily-- only after they are tagged dirty. Also, cached bounds are also shared when copying geometry data-blocks that have equivalent data. When bounds are calculated on an evaluated data-block, they are also accessible on the original, and the next evaluated ID will also share them. A geometry will stop sharing bounds as soon as its positions (or radii) are changed. Just caching the bounds gave a 2-3x speedup with thousands of mesh geometry instances in the viewport. Sharing the bounds can eliminate recalculations entirely in cases like copying meshes in geometry nodes or the selection paint brush in curves sculpt mode, which causes a reevaluation but doesn't change the positions. **Implementation** The sharing is achieved with a `shared_ptr` that points to a cache mutex (from D16419) and the cached bounds data. When geometries are copied, the bounds are shared by default, and only "un-shared" when the bounds are tagged dirty. Point clouds have a new runtime struct to store this data. Functions for tagging the data dirty are improved for added for point clouds and improved for curves. A missing tag has also been fixed for mesh sculpt mode. **Future** There are further improvements which can be worked on next - Apply changes to volume objects and other types where it makes sense - Continue cleanup changes described in T96968 - Apply shared cache design to more expensive data like triangulation or normals Differential Revision: https://developer.blender.org/D16204
2022-11-15 13:46:55 -06:00
#include "BLI_math_vector.hh"
#include "BLI_rand.h"
#include "BLI_span.hh"
#include "BLI_task.hh"
#include "BLI_utildefines.h"
#include "BLI_vector.hh"
#include "BKE_anim_data.hh"
Geometry Nodes: support baking data block references With this patch, materials are kept intact in simulation zones and bake nodes without any additional user action. This implements the design proposed in #108410 to support referencing data-blocks (only materials for now) in the baked data. The task also describes why this is not a trivial issue. A previous attempt was implemented in #109703 but it didn't work well-enough. The solution is to have an explicit `name (+ library name) -> data-block` mapping that is stored in the modifier for each bake node and simulation zone. The `library name` is necessary for it to be unique within a .blend file. Note that this refers to the name of the `Library` data-block and not a file path. The baked data only contains the names of the used data-blocks. When the baked data is loaded, the correct material data-block is looked up from the mapping. ### Automatic Mapping Generation The most tricky aspect of this approach is to make it feel mostly automatic. From the user point-of-view, it should just work. Therefore, we don't want the user to have to create the mapping manually in the majority of cases. Creating the mapping automatically is difficult because the data-blocks that should become part of the mapping are only known during depsgraph evaluation. So we somehow have to gather the missing data blocks during evaluation and then write the new mappings back to the original data. While writing back to original data is something we do in some cases already, the situation here is different, because we are actually creating new relations between data-blocks. This also means that we'll have to do user-counting. Since user counts in data-blocks are *not* atomic, we can't do that from multiple threads at the same time. Also, under some circumstances, it may be necessary to trigger depsgraph evaluation again after the write-back because it actually affects the result. To solve this, a small new API is added in `DEG_depsgraph_writeback_sync.hh`. It allows gathering tasks which write back to original data in a synchronous way which may also require a reevaluation. ### Accessing the Mapping A new `BakeDataBlockMap` is passed to geometry nodes evaluation by the modifier. This map allows getting the `ID` pointer that should be used for a specific data-block name that is stored in baked data. It's also used to gather all the missing data mappings during evaluation. ### Weak ID References The baked/cached geometries may have references to other data-blocks (currently only materials, but in the future also e.g. instanced objects/collections). However, the pointers of these data-blocks are not stable over time. That is especially true when storing/loading the data from disk, but also just when playing back the animation. Therefore, the used data-blocks have to referenced in a different way at run-time. This is solved by adding `std::unique_ptr<bake::BakeMaterialsList>` to the run-time data of various geometry data-blocks. If the data-block is cached over a longer period of time (such that material pointers can't be used directly), it stores the material name (+ library name) used by each material slot. When the geometry is used again, the material pointers are restored using these weak name references and the `BakeDataBlockMap`. ### Manual Mapping Management There is a new `Data-Blocks` panel in the bake settings in the node editor sidebar that allows inspecting and modifying the data-blocks that are used when baking. The user can change what data-block a specific name is mapped to. Pull Request: https://projects.blender.org/blender/blender/pulls/117043
2024-02-01 09:21:55 +01:00
#include "BKE_bake_data_block_id.hh"
#include "BKE_customdata.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_geometry_set.hh"
#include "BKE_idtype.hh"
2024-01-15 12:44:04 -05:00
#include "BKE_lib_id.hh"
#include "BKE_lib_query.hh"
2023-11-14 09:30:40 +01:00
#include "BKE_modifier.hh"
#include "BKE_object.hh"
#include "BKE_object_types.hh"
#include "BKE_pointcloud.hh"
#include "BLT_translation.hh"
#include "DEG_depsgraph_query.hh"
#include "BLO_read_write.hh"
using blender::float3;
using blender::IndexRange;
using blender::MutableSpan;
using blender::Span;
using blender::Vector;
/* PointCloud datablock */
static void pointcloud_random(PointCloud *pointcloud);
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 char *POINTCLOUD_ATTR_POSITION = "position";
const char *POINTCLOUD_ATTR_RADIUS = "radius";
static void pointcloud_init_data(ID *id)
{
PointCloud *pointcloud = (PointCloud *)id;
BLI_assert(MEMCMP_STRUCT_AFTER_IS_ZERO(pointcloud, id));
MEMCPY_STRUCT_AFTER(pointcloud, DNA_struct_default_get(PointCloud), id);
pointcloud->runtime = new blender::bke::PointCloudRuntime();
CustomData_reset(&pointcloud->pdata);
pointcloud->attributes_for_write().add<float3>(
"position", blender::bke::AttrDomain::Point, blender::bke::AttributeInitConstruct());
}
Custom Data: support implicit sharing for custom data layers This integrates the new implicit-sharing system (from fbcddfcd68adc72f) with `CustomData`. Now the potentially long arrays referenced by custom data layers can be shared between different systems but most importantly between different geometries. This makes e.g. copying a mesh much cheaper because none of the attributes has to be copied. Only when an attribute is modified does it have to be copied. Also see the original design task: #95845. This reduces memory and improves performance by avoiding unnecessary data copies. For example, the used memory after loading a highly subdivided mesh is reduced from 2.4GB to 1.79GB. This is about 25% less which is the expected amount because in `main` there are 4 copies of the data: 1. The original data which is allocated when the file is loaded. 2. The copy for the depsgraph allocated during depsgraph evaluation. 3. The copy for the undo system allocated when the first undo step is created right after loading the file. 4. GPU buffers allocated for drawing. This patch only gets rid of copy number 2 for the depsgraph. In theory the other copies can be removed as part of follow up PRs as well though. ----- The patch has three main components: * Slightly modified `CustomData` API to make it work better with implicit sharing: * `CD_REFERENCE` and `CD_DUPLICATE` have been removed because they are meaningless when implicit-sharing is used. * `CD_ASSIGN` has been removed as well because it's not an allocation type anyway. The functionality of using existing arrays as custom data layers has not been removed though. * This can still be done with `CustomData_add_layer_with_data` which also has a new argument that allows passing in information about whether the array is shared. * `CD_FLAG_NOFREE` has been removed because it's no longer necessary. It only existed because of `CD_REFERENCE`. * `CustomData_copy` and `CustomData_merge` have been split up into a functions that do copy the actual attribute values and those that do not. The latter functions now have the `_layout` suffix (e.g. `CustomData_copy_layout`). * Changes in `customdata.cc` to make it actually use implicit-sharing. * Changes in various other files to adapt to the changes in `BKE_customdata.h`. Pull Request: https://projects.blender.org/blender/blender/pulls/106228
2023-04-13 14:57:57 +02:00
static void pointcloud_copy_data(Main * /*bmain*/,
std::optional<Library *> /*owner_library*/,
Custom Data: support implicit sharing for custom data layers This integrates the new implicit-sharing system (from fbcddfcd68adc72f) with `CustomData`. Now the potentially long arrays referenced by custom data layers can be shared between different systems but most importantly between different geometries. This makes e.g. copying a mesh much cheaper because none of the attributes has to be copied. Only when an attribute is modified does it have to be copied. Also see the original design task: #95845. This reduces memory and improves performance by avoiding unnecessary data copies. For example, the used memory after loading a highly subdivided mesh is reduced from 2.4GB to 1.79GB. This is about 25% less which is the expected amount because in `main` there are 4 copies of the data: 1. The original data which is allocated when the file is loaded. 2. The copy for the depsgraph allocated during depsgraph evaluation. 3. The copy for the undo system allocated when the first undo step is created right after loading the file. 4. GPU buffers allocated for drawing. This patch only gets rid of copy number 2 for the depsgraph. In theory the other copies can be removed as part of follow up PRs as well though. ----- The patch has three main components: * Slightly modified `CustomData` API to make it work better with implicit sharing: * `CD_REFERENCE` and `CD_DUPLICATE` have been removed because they are meaningless when implicit-sharing is used. * `CD_ASSIGN` has been removed as well because it's not an allocation type anyway. The functionality of using existing arrays as custom data layers has not been removed though. * This can still be done with `CustomData_add_layer_with_data` which also has a new argument that allows passing in information about whether the array is shared. * `CD_FLAG_NOFREE` has been removed because it's no longer necessary. It only existed because of `CD_REFERENCE`. * `CustomData_copy` and `CustomData_merge` have been split up into a functions that do copy the actual attribute values and those that do not. The latter functions now have the `_layout` suffix (e.g. `CustomData_copy_layout`). * Changes in `customdata.cc` to make it actually use implicit-sharing. * Changes in various other files to adapt to the changes in `BKE_customdata.h`. Pull Request: https://projects.blender.org/blender/blender/pulls/106228
2023-04-13 14:57:57 +02:00
ID *id_dst,
const ID *id_src,
const int /*flag*/)
{
PointCloud *pointcloud_dst = (PointCloud *)id_dst;
const PointCloud *pointcloud_src = (const PointCloud *)id_src;
pointcloud_dst->mat = static_cast<Material **>(MEM_dupallocN(pointcloud_src->mat));
CustomData_init_from(
Custom Data: support implicit sharing for custom data layers This integrates the new implicit-sharing system (from fbcddfcd68adc72f) with `CustomData`. Now the potentially long arrays referenced by custom data layers can be shared between different systems but most importantly between different geometries. This makes e.g. copying a mesh much cheaper because none of the attributes has to be copied. Only when an attribute is modified does it have to be copied. Also see the original design task: #95845. This reduces memory and improves performance by avoiding unnecessary data copies. For example, the used memory after loading a highly subdivided mesh is reduced from 2.4GB to 1.79GB. This is about 25% less which is the expected amount because in `main` there are 4 copies of the data: 1. The original data which is allocated when the file is loaded. 2. The copy for the depsgraph allocated during depsgraph evaluation. 3. The copy for the undo system allocated when the first undo step is created right after loading the file. 4. GPU buffers allocated for drawing. This patch only gets rid of copy number 2 for the depsgraph. In theory the other copies can be removed as part of follow up PRs as well though. ----- The patch has three main components: * Slightly modified `CustomData` API to make it work better with implicit sharing: * `CD_REFERENCE` and `CD_DUPLICATE` have been removed because they are meaningless when implicit-sharing is used. * `CD_ASSIGN` has been removed as well because it's not an allocation type anyway. The functionality of using existing arrays as custom data layers has not been removed though. * This can still be done with `CustomData_add_layer_with_data` which also has a new argument that allows passing in information about whether the array is shared. * `CD_FLAG_NOFREE` has been removed because it's no longer necessary. It only existed because of `CD_REFERENCE`. * `CustomData_copy` and `CustomData_merge` have been split up into a functions that do copy the actual attribute values and those that do not. The latter functions now have the `_layout` suffix (e.g. `CustomData_copy_layout`). * Changes in `customdata.cc` to make it actually use implicit-sharing. * Changes in various other files to adapt to the changes in `BKE_customdata.h`. Pull Request: https://projects.blender.org/blender/blender/pulls/106228
2023-04-13 14:57:57 +02:00
&pointcloud_src->pdata, &pointcloud_dst->pdata, CD_MASK_ALL, pointcloud_dst->totpoint);
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: Cache bounds min and max, share between data-blocks Bounding box calculation can be a large in some situations, especially instancing. This patch caches the min and max of the bounding box in runtime data of meshes, point clouds, and curves, implementing part of T96968. Bounds are now calculated lazily-- only after they are tagged dirty. Also, cached bounds are also shared when copying geometry data-blocks that have equivalent data. When bounds are calculated on an evaluated data-block, they are also accessible on the original, and the next evaluated ID will also share them. A geometry will stop sharing bounds as soon as its positions (or radii) are changed. Just caching the bounds gave a 2-3x speedup with thousands of mesh geometry instances in the viewport. Sharing the bounds can eliminate recalculations entirely in cases like copying meshes in geometry nodes or the selection paint brush in curves sculpt mode, which causes a reevaluation but doesn't change the positions. **Implementation** The sharing is achieved with a `shared_ptr` that points to a cache mutex (from D16419) and the cached bounds data. When geometries are copied, the bounds are shared by default, and only "un-shared" when the bounds are tagged dirty. Point clouds have a new runtime struct to store this data. Functions for tagging the data dirty are improved for added for point clouds and improved for curves. A missing tag has also been fixed for mesh sculpt mode. **Future** There are further improvements which can be worked on next - Apply changes to volume objects and other types where it makes sense - Continue cleanup changes described in T96968 - Apply shared cache design to more expensive data like triangulation or normals Differential Revision: https://developer.blender.org/D16204
2022-11-15 13:46:55 -06:00
pointcloud_dst->runtime = new blender::bke::PointCloudRuntime();
pointcloud_dst->runtime->bounds_cache = pointcloud_src->runtime->bounds_cache;
Geometry Nodes: support baking data block references With this patch, materials are kept intact in simulation zones and bake nodes without any additional user action. This implements the design proposed in #108410 to support referencing data-blocks (only materials for now) in the baked data. The task also describes why this is not a trivial issue. A previous attempt was implemented in #109703 but it didn't work well-enough. The solution is to have an explicit `name (+ library name) -> data-block` mapping that is stored in the modifier for each bake node and simulation zone. The `library name` is necessary for it to be unique within a .blend file. Note that this refers to the name of the `Library` data-block and not a file path. The baked data only contains the names of the used data-blocks. When the baked data is loaded, the correct material data-block is looked up from the mapping. ### Automatic Mapping Generation The most tricky aspect of this approach is to make it feel mostly automatic. From the user point-of-view, it should just work. Therefore, we don't want the user to have to create the mapping manually in the majority of cases. Creating the mapping automatically is difficult because the data-blocks that should become part of the mapping are only known during depsgraph evaluation. So we somehow have to gather the missing data blocks during evaluation and then write the new mappings back to the original data. While writing back to original data is something we do in some cases already, the situation here is different, because we are actually creating new relations between data-blocks. This also means that we'll have to do user-counting. Since user counts in data-blocks are *not* atomic, we can't do that from multiple threads at the same time. Also, under some circumstances, it may be necessary to trigger depsgraph evaluation again after the write-back because it actually affects the result. To solve this, a small new API is added in `DEG_depsgraph_writeback_sync.hh`. It allows gathering tasks which write back to original data in a synchronous way which may also require a reevaluation. ### Accessing the Mapping A new `BakeDataBlockMap` is passed to geometry nodes evaluation by the modifier. This map allows getting the `ID` pointer that should be used for a specific data-block name that is stored in baked data. It's also used to gather all the missing data mappings during evaluation. ### Weak ID References The baked/cached geometries may have references to other data-blocks (currently only materials, but in the future also e.g. instanced objects/collections). However, the pointers of these data-blocks are not stable over time. That is especially true when storing/loading the data from disk, but also just when playing back the animation. Therefore, the used data-blocks have to referenced in a different way at run-time. This is solved by adding `std::unique_ptr<bake::BakeMaterialsList>` to the run-time data of various geometry data-blocks. If the data-block is cached over a longer period of time (such that material pointers can't be used directly), it stores the material name (+ library name) used by each material slot. When the geometry is used again, the material pointers are restored using these weak name references and the `BakeDataBlockMap`. ### Manual Mapping Management There is a new `Data-Blocks` panel in the bake settings in the node editor sidebar that allows inspecting and modifying the data-blocks that are used when baking. The user can change what data-block a specific name is mapped to. Pull Request: https://projects.blender.org/blender/blender/pulls/117043
2024-02-01 09:21:55 +01:00
if (pointcloud_src->runtime->bake_materials) {
pointcloud_dst->runtime->bake_materials =
std::make_unique<blender::bke::bake::BakeMaterialsList>(
*pointcloud_src->runtime->bake_materials);
}
Geometry: Cache bounds min and max, share between data-blocks Bounding box calculation can be a large in some situations, especially instancing. This patch caches the min and max of the bounding box in runtime data of meshes, point clouds, and curves, implementing part of T96968. Bounds are now calculated lazily-- only after they are tagged dirty. Also, cached bounds are also shared when copying geometry data-blocks that have equivalent data. When bounds are calculated on an evaluated data-block, they are also accessible on the original, and the next evaluated ID will also share them. A geometry will stop sharing bounds as soon as its positions (or radii) are changed. Just caching the bounds gave a 2-3x speedup with thousands of mesh geometry instances in the viewport. Sharing the bounds can eliminate recalculations entirely in cases like copying meshes in geometry nodes or the selection paint brush in curves sculpt mode, which causes a reevaluation but doesn't change the positions. **Implementation** The sharing is achieved with a `shared_ptr` that points to a cache mutex (from D16419) and the cached bounds data. When geometries are copied, the bounds are shared by default, and only "un-shared" when the bounds are tagged dirty. Point clouds have a new runtime struct to store this data. Functions for tagging the data dirty are improved for added for point clouds and improved for curves. A missing tag has also been fixed for mesh sculpt mode. **Future** There are further improvements which can be worked on next - Apply changes to volume objects and other types where it makes sense - Continue cleanup changes described in T96968 - Apply shared cache design to more expensive data like triangulation or normals Differential Revision: https://developer.blender.org/D16204
2022-11-15 13:46:55 -06: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
pointcloud_dst->batch_cache = nullptr;
}
static void pointcloud_free_data(ID *id)
{
PointCloud *pointcloud = (PointCloud *)id;
BKE_animdata_free(&pointcloud->id, false);
BKE_pointcloud_batch_cache_free(pointcloud);
CustomData_free(&pointcloud->pdata, pointcloud->totpoint);
MEM_SAFE_FREE(pointcloud->mat);
Geometry: Cache bounds min and max, share between data-blocks Bounding box calculation can be a large in some situations, especially instancing. This patch caches the min and max of the bounding box in runtime data of meshes, point clouds, and curves, implementing part of T96968. Bounds are now calculated lazily-- only after they are tagged dirty. Also, cached bounds are also shared when copying geometry data-blocks that have equivalent data. When bounds are calculated on an evaluated data-block, they are also accessible on the original, and the next evaluated ID will also share them. A geometry will stop sharing bounds as soon as its positions (or radii) are changed. Just caching the bounds gave a 2-3x speedup with thousands of mesh geometry instances in the viewport. Sharing the bounds can eliminate recalculations entirely in cases like copying meshes in geometry nodes or the selection paint brush in curves sculpt mode, which causes a reevaluation but doesn't change the positions. **Implementation** The sharing is achieved with a `shared_ptr` that points to a cache mutex (from D16419) and the cached bounds data. When geometries are copied, the bounds are shared by default, and only "un-shared" when the bounds are tagged dirty. Point clouds have a new runtime struct to store this data. Functions for tagging the data dirty are improved for added for point clouds and improved for curves. A missing tag has also been fixed for mesh sculpt mode. **Future** There are further improvements which can be worked on next - Apply changes to volume objects and other types where it makes sense - Continue cleanup changes described in T96968 - Apply shared cache design to more expensive data like triangulation or normals Differential Revision: https://developer.blender.org/D16204
2022-11-15 13:46:55 -06:00
delete pointcloud->runtime;
}
static void pointcloud_foreach_id(ID *id, LibraryForeachIDData *data)
{
PointCloud *pointcloud = (PointCloud *)id;
for (int i = 0; i < pointcloud->totcol; i++) {
BKE_LIB_FOREACHID_PROCESS_IDSUPER(data, pointcloud->mat[i], IDWALK_CB_USER);
}
}
static void pointcloud_blend_write(BlendWriter *writer, ID *id, const void *id_address)
{
PointCloud *pointcloud = (PointCloud *)id;
Vector<CustomDataLayer, 16> point_layers;
CustomData_blend_write_prepare(pointcloud->pdata, point_layers);
/* Write LibData */
BLO_write_id_struct(writer, PointCloud, id_address, &pointcloud->id);
BKE_id_blend_write(writer, &pointcloud->id);
/* Direct data */
CustomData_blend_write(writer,
&pointcloud->pdata,
point_layers,
pointcloud->totpoint,
CD_MASK_ALL,
&pointcloud->id);
BLO_write_pointer_array(writer, pointcloud->totcol, pointcloud->mat);
}
static void pointcloud_blend_read_data(BlendDataReader *reader, ID *id)
{
PointCloud *pointcloud = (PointCloud *)id;
/* Geometry */
CustomData_blend_read(reader, &pointcloud->pdata, pointcloud->totpoint);
/* Materials */
BLO_read_pointer_array(reader, pointcloud->totcol, (void **)&pointcloud->mat);
Geometry: Cache bounds min and max, share between data-blocks Bounding box calculation can be a large in some situations, especially instancing. This patch caches the min and max of the bounding box in runtime data of meshes, point clouds, and curves, implementing part of T96968. Bounds are now calculated lazily-- only after they are tagged dirty. Also, cached bounds are also shared when copying geometry data-blocks that have equivalent data. When bounds are calculated on an evaluated data-block, they are also accessible on the original, and the next evaluated ID will also share them. A geometry will stop sharing bounds as soon as its positions (or radii) are changed. Just caching the bounds gave a 2-3x speedup with thousands of mesh geometry instances in the viewport. Sharing the bounds can eliminate recalculations entirely in cases like copying meshes in geometry nodes or the selection paint brush in curves sculpt mode, which causes a reevaluation but doesn't change the positions. **Implementation** The sharing is achieved with a `shared_ptr` that points to a cache mutex (from D16419) and the cached bounds data. When geometries are copied, the bounds are shared by default, and only "un-shared" when the bounds are tagged dirty. Point clouds have a new runtime struct to store this data. Functions for tagging the data dirty are improved for added for point clouds and improved for curves. A missing tag has also been fixed for mesh sculpt mode. **Future** There are further improvements which can be worked on next - Apply changes to volume objects and other types where it makes sense - Continue cleanup changes described in T96968 - Apply shared cache design to more expensive data like triangulation or normals Differential Revision: https://developer.blender.org/D16204
2022-11-15 13:46:55 -06:00
pointcloud->runtime = new blender::bke::PointCloudRuntime();
}
IDTypeInfo IDType_ID_PT = {
/*id_code*/ ID_PT,
/*id_filter*/ FILTER_ID_PT,
/*dependencies_id_types*/ FILTER_ID_MA,
/*main_listbase_index*/ INDEX_ID_PT,
/*struct_size*/ sizeof(PointCloud),
/*name*/ "PointCloud",
/*name_plural*/ N_("pointclouds"),
/*translation_context*/ BLT_I18NCONTEXT_ID_POINTCLOUD,
/*flags*/ IDTYPE_FLAGS_APPEND_IS_REUSABLE,
/*asset_type_info*/ nullptr,
/*init_data*/ pointcloud_init_data,
/*copy_data*/ pointcloud_copy_data,
/*free_data*/ pointcloud_free_data,
/*make_local*/ nullptr,
/*foreach_id*/ pointcloud_foreach_id,
/*foreach_cache*/ nullptr,
/*foreach_path*/ nullptr,
/*owner_pointer_get*/ nullptr,
/*blend_write*/ pointcloud_blend_write,
/*blend_read_data*/ pointcloud_blend_read_data,
/*blend_read_after_liblink*/ nullptr,
/*blend_read_undo_preserve*/ nullptr,
/*lib_override_apply_post*/ nullptr,
};
static void pointcloud_random(PointCloud *pointcloud)
{
BLI_assert(pointcloud->totpoint == 0);
pointcloud->totpoint = 400;
CustomData_realloc(&pointcloud->pdata, 0, pointcloud->totpoint);
RNG *rng = BLI_rng_new(0);
blender::bke::MutableAttributeAccessor attributes = pointcloud->attributes_for_write();
blender::MutableSpan<float3> positions = pointcloud->positions_for_write();
blender::bke::SpanAttributeWriter<float> radii =
attributes.lookup_or_add_for_write_only_span<float>(POINTCLOUD_ATTR_RADIUS,
blender::bke::AttrDomain::Point);
for (const int i : positions.index_range()) {
positions[i] = float3(BLI_rng_get_float(rng), BLI_rng_get_float(rng), BLI_rng_get_float(rng)) *
2.0f -
1.0f;
radii.span[i] = 0.05f * BLI_rng_get_float(rng);
}
radii.finish();
BLI_rng_free(rng);
}
Span<float3> PointCloud::positions() const
{
return {static_cast<const float3 *>(
CustomData_get_layer_named(&this->pdata, CD_PROP_FLOAT3, "position")),
this->totpoint};
}
MutableSpan<float3> PointCloud::positions_for_write()
{
return {static_cast<float3 *>(CustomData_get_layer_named_for_write(
&this->pdata, CD_PROP_FLOAT3, "position", this->totpoint)),
this->totpoint};
}
void *BKE_pointcloud_add(Main *bmain, const char *name)
{
PointCloud *pointcloud = static_cast<PointCloud *>(BKE_id_new(bmain, ID_PT, name));
return pointcloud;
}
void *BKE_pointcloud_add_default(Main *bmain, const char *name)
{
PointCloud *pointcloud = static_cast<PointCloud *>(BKE_libblock_alloc(bmain, ID_PT, name, 0));
pointcloud_init_data(&pointcloud->id);
pointcloud_random(pointcloud);
return pointcloud;
}
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
PointCloud *BKE_pointcloud_new_nomain(const int totpoint)
{
PointCloud *pointcloud = static_cast<PointCloud *>(BKE_libblock_alloc(
nullptr, ID_PT, BKE_idtype_idcode_to_name(ID_PT), LIB_ID_CREATE_LOCALIZE));
pointcloud_init_data(&pointcloud->id);
CustomData_realloc(&pointcloud->pdata, 0, totpoint);
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
pointcloud->totpoint = totpoint;
return pointcloud;
}
void BKE_pointcloud_nomain_to_pointcloud(PointCloud *pointcloud_src, PointCloud *pointcloud_dst)
{
BLI_assert(pointcloud_src->id.tag & ID_TAG_NO_MAIN);
CustomData_free(&pointcloud_dst->pdata, pointcloud_dst->totpoint);
const int totpoint = pointcloud_dst->totpoint = pointcloud_src->totpoint;
CustomData_init_from(&pointcloud_src->pdata, &pointcloud_dst->pdata, CD_MASK_ALL, totpoint);
BKE_id_free(nullptr, pointcloud_src);
}
std::optional<blender::Bounds<blender::float3>> PointCloud::bounds_min_max() 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
{
using namespace blender;
Geometry: Cache bounds min and max, share between data-blocks Bounding box calculation can be a large in some situations, especially instancing. This patch caches the min and max of the bounding box in runtime data of meshes, point clouds, and curves, implementing part of T96968. Bounds are now calculated lazily-- only after they are tagged dirty. Also, cached bounds are also shared when copying geometry data-blocks that have equivalent data. When bounds are calculated on an evaluated data-block, they are also accessible on the original, and the next evaluated ID will also share them. A geometry will stop sharing bounds as soon as its positions (or radii) are changed. Just caching the bounds gave a 2-3x speedup with thousands of mesh geometry instances in the viewport. Sharing the bounds can eliminate recalculations entirely in cases like copying meshes in geometry nodes or the selection paint brush in curves sculpt mode, which causes a reevaluation but doesn't change the positions. **Implementation** The sharing is achieved with a `shared_ptr` that points to a cache mutex (from D16419) and the cached bounds data. When geometries are copied, the bounds are shared by default, and only "un-shared" when the bounds are tagged dirty. Point clouds have a new runtime struct to store this data. Functions for tagging the data dirty are improved for added for point clouds and improved for curves. A missing tag has also been fixed for mesh sculpt mode. **Future** There are further improvements which can be worked on next - Apply changes to volume objects and other types where it makes sense - Continue cleanup changes described in T96968 - Apply shared cache design to more expensive data like triangulation or normals Differential Revision: https://developer.blender.org/D16204
2022-11-15 13:46:55 -06:00
using namespace blender::bke;
if (this->totpoint == 0) {
return std::nullopt;
}
Geometry: Cache bounds min and max, share between data-blocks Bounding box calculation can be a large in some situations, especially instancing. This patch caches the min and max of the bounding box in runtime data of meshes, point clouds, and curves, implementing part of T96968. Bounds are now calculated lazily-- only after they are tagged dirty. Also, cached bounds are also shared when copying geometry data-blocks that have equivalent data. When bounds are calculated on an evaluated data-block, they are also accessible on the original, and the next evaluated ID will also share them. A geometry will stop sharing bounds as soon as its positions (or radii) are changed. Just caching the bounds gave a 2-3x speedup with thousands of mesh geometry instances in the viewport. Sharing the bounds can eliminate recalculations entirely in cases like copying meshes in geometry nodes or the selection paint brush in curves sculpt mode, which causes a reevaluation but doesn't change the positions. **Implementation** The sharing is achieved with a `shared_ptr` that points to a cache mutex (from D16419) and the cached bounds data. When geometries are copied, the bounds are shared by default, and only "un-shared" when the bounds are tagged dirty. Point clouds have a new runtime struct to store this data. Functions for tagging the data dirty are improved for added for point clouds and improved for curves. A missing tag has also been fixed for mesh sculpt mode. **Future** There are further improvements which can be worked on next - Apply changes to volume objects and other types where it makes sense - Continue cleanup changes described in T96968 - Apply shared cache design to more expensive data like triangulation or normals Differential Revision: https://developer.blender.org/D16204
2022-11-15 13:46:55 -06:00
this->runtime->bounds_cache.ensure([&](Bounds<float3> &r_bounds) {
const AttributeAccessor attributes = this->attributes();
const Span<float3> positions = this->positions();
Geometry: Cache bounds min and max, share between data-blocks Bounding box calculation can be a large in some situations, especially instancing. This patch caches the min and max of the bounding box in runtime data of meshes, point clouds, and curves, implementing part of T96968. Bounds are now calculated lazily-- only after they are tagged dirty. Also, cached bounds are also shared when copying geometry data-blocks that have equivalent data. When bounds are calculated on an evaluated data-block, they are also accessible on the original, and the next evaluated ID will also share them. A geometry will stop sharing bounds as soon as its positions (or radii) are changed. Just caching the bounds gave a 2-3x speedup with thousands of mesh geometry instances in the viewport. Sharing the bounds can eliminate recalculations entirely in cases like copying meshes in geometry nodes or the selection paint brush in curves sculpt mode, which causes a reevaluation but doesn't change the positions. **Implementation** The sharing is achieved with a `shared_ptr` that points to a cache mutex (from D16419) and the cached bounds data. When geometries are copied, the bounds are shared by default, and only "un-shared" when the bounds are tagged dirty. Point clouds have a new runtime struct to store this data. Functions for tagging the data dirty are improved for added for point clouds and improved for curves. A missing tag has also been fixed for mesh sculpt mode. **Future** There are further improvements which can be worked on next - Apply changes to volume objects and other types where it makes sense - Continue cleanup changes described in T96968 - Apply shared cache design to more expensive data like triangulation or normals Differential Revision: https://developer.blender.org/D16204
2022-11-15 13:46:55 -06:00
if (attributes.contains(POINTCLOUD_ATTR_RADIUS)) {
const VArraySpan radii = *attributes.lookup<float>(POINTCLOUD_ATTR_RADIUS);
Geometry: Cache bounds min and max, share between data-blocks Bounding box calculation can be a large in some situations, especially instancing. This patch caches the min and max of the bounding box in runtime data of meshes, point clouds, and curves, implementing part of T96968. Bounds are now calculated lazily-- only after they are tagged dirty. Also, cached bounds are also shared when copying geometry data-blocks that have equivalent data. When bounds are calculated on an evaluated data-block, they are also accessible on the original, and the next evaluated ID will also share them. A geometry will stop sharing bounds as soon as its positions (or radii) are changed. Just caching the bounds gave a 2-3x speedup with thousands of mesh geometry instances in the viewport. Sharing the bounds can eliminate recalculations entirely in cases like copying meshes in geometry nodes or the selection paint brush in curves sculpt mode, which causes a reevaluation but doesn't change the positions. **Implementation** The sharing is achieved with a `shared_ptr` that points to a cache mutex (from D16419) and the cached bounds data. When geometries are copied, the bounds are shared by default, and only "un-shared" when the bounds are tagged dirty. Point clouds have a new runtime struct to store this data. Functions for tagging the data dirty are improved for added for point clouds and improved for curves. A missing tag has also been fixed for mesh sculpt mode. **Future** There are further improvements which can be worked on next - Apply changes to volume objects and other types where it makes sense - Continue cleanup changes described in T96968 - Apply shared cache design to more expensive data like triangulation or normals Differential Revision: https://developer.blender.org/D16204
2022-11-15 13:46:55 -06:00
r_bounds = *bounds::min_max_with_radii(positions, radii);
}
else {
r_bounds = *bounds::min_max(positions);
}
});
return this->runtime->bounds_cache.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
}
Core: introduce MemoryCounter API We often have the situation where it would be good if we could easily estimate the memory usage of some value (e.g. a mesh, or volume). Examples of where we ran into this in the past: * Undo step size. * Caching of volume grids. * Caching of loaded geometries for import geometry nodes. Generally, most caching systems would benefit from the ability to know how much memory they currently use to make better decisions about which data to free and when. The goal of this patch is to introduce a simple general API to count the memory usage that is independent of any specific caching system. I'm doing this to "fix" the chicken and egg problem that caches need to know the memory usage, but we don't really need to count the memory usage without using it for caches. Implementing caching and memory counting at the same time make both harder than implementing them one after another. The main difficulty with counting memory usage is that some memory may be shared using implicit sharing. We want to avoid double counting such memory. How exactly shared memory is treated depends a bit on the use case, so no specific assumptions are made about that in the API. The gathered memory usage is not expected to be exact. It's expected to be a decent approximation. It's neither a lower nor an upper bound unless specified by some specific type. Cache systems generally build on top of heuristics to decide when to free what anyway. There are two sides to this API: 1. Get the amount of memory used by one or more values. This side is used by caching systems and/or systems that want to present the used memory to the user. 2. Tell the caller how much memory is used. This side is used by all kinds of types that can report their memory usage such as meshes. ```cpp /* Get how much memory is used by two meshes together. */ MemoryCounter memory; mesh_a->count_memory(memory); mesh_b->count_memory(memory); int64_t bytes_used = memory.counted_bytes(); /* Tell the caller how much memory is used. */ void Mesh::count_memory(blender::MemoryCounter &memory) const { memory.add_shared(this->runtime->face_offsets_sharing_info, this->face_offsets().size_in_bytes()); /* Forward memory counting to lower level types. This should be fairly common. */ CustomData_count_memory(this->vert_data, this->verts_num, memory); } void CustomData_count_memory(const CustomData &data, const int totelem, blender::MemoryCounter &memory) { for (const CustomDataLayer &layer : Span{data.layers, data.totlayer}) { memory.add_shared(layer.sharing_info, [&](blender::MemoryCounter &shared_memory) { /* Not quite correct for all types, but this is only a rough approximation anyway. */ const int64_t elem_size = CustomData_get_elem_size(&layer); shared_memory.add(totelem * elem_size); }); } } ``` Pull Request: https://projects.blender.org/blender/blender/pulls/126295
2024-08-15 10:54:21 +02:00
void PointCloud::count_memory(blender::MemoryCounter &memory) const
{
CustomData_count_memory(this->pdata, this->totpoint, memory);
}
bool BKE_pointcloud_attribute_required(const PointCloud * /*pointcloud*/, const char *name)
{
return STREQ(name, POINTCLOUD_ATTR_POSITION);
}
/* Dependency Graph */
PointCloud *BKE_pointcloud_copy_for_eval(const PointCloud *pointcloud_src)
{
return reinterpret_cast<PointCloud *>(
BKE_id_copy_ex(nullptr, &pointcloud_src->id, nullptr, LIB_ID_COPY_LOCALIZE));
}
static void pointcloud_evaluate_modifiers(Depsgraph *depsgraph,
Scene *scene,
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
Object *object,
blender::bke::GeometrySet &geometry_set)
{
/* Modifier evaluation modes. */
const bool use_render = (DEG_get_mode(depsgraph) == DAG_EVAL_RENDER);
const int required_mode = use_render ? eModifierMode_Render : eModifierMode_Realtime;
ModifierApplyFlag apply_flag = use_render ? MOD_APPLY_RENDER : MOD_APPLY_USECACHE;
const ModifierEvalContext mectx = {depsgraph, object, apply_flag};
BKE_modifiers_clear_errors(object);
/* Get effective list of modifiers to execute. Some effects like shape keys
* are added as virtual modifiers before the user created modifiers. */
VirtualModifierData virtual_modifier_data;
ModifierData *md = BKE_modifiers_get_virtual_modifierlist(object, &virtual_modifier_data);
/* Evaluate modifiers. */
for (; md; md = md->next) {
const ModifierTypeInfo *mti = BKE_modifier_get_info((ModifierType)md->type);
if (!BKE_modifier_is_enabled(scene, md, required_mode)) {
continue;
}
Modifiers: measure execution time and provide Python access The goal is to give technical artists the ability to optimize modifier usage and/or geometry node groups for performance. In the long term, it would be useful if Blender could provide its own UI to display profiling information to users. However, right now, there are too many open design questions making it infeasible to tackle this in the short term. This commit uses a simpler approach: Instead of adding new ui for profiling data, it exposes the execution-time of modifiers in the Python API. This allows technical artists to access the information and to build their own UI to display the relevant information. In the long term this will hopefully also help us to integrate a native ui for this in Blender by observing how users use this information. Note: The execution time of a modifier highly depends on what other things the CPU is doing at the same time. For example, in many more complex files, many objects and therefore modifiers are evaluated at the same time by multiple threads which makes the measurement much less reliable. For best results, make sure that only one object is evaluated at a time (e.g. by changing it in isolation) and that no other process on the system keeps the CPU busy. As shown below, the execution time has to be accessed on the evaluated object, not the original object. ```lang=python import bpy depsgraph = bpy.context.view_layer.depsgraph ob = bpy.context.active_object ob_eval = ob.evaluated_get(depsgraph) modifier_eval = ob_eval.modifiers[0] print(modifier_eval.execution_time, "s") ``` Differential Revision: https://developer.blender.org/D17185
2023-02-06 15:39:59 +01:00
blender::bke::ScopedModifierTimer modifier_timer{*md};
if (mti->modify_geometry_set) {
mti->modify_geometry_set(md, &mectx, &geometry_set);
}
}
}
static PointCloud *take_pointcloud_ownership_from_geometry_set(
blender::bke::GeometrySet &geometry_set)
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
{
if (!geometry_set.has<blender::bke::PointCloudComponent>()) {
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
return nullptr;
}
blender::bke::PointCloudComponent &pointcloud_component =
geometry_set.get_component_for_write<blender::bke::PointCloudComponent>();
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
PointCloud *pointcloud = pointcloud_component.release();
if (pointcloud != nullptr) {
/* Add back, but as read-only non-owning component. */
pointcloud_component.replace(pointcloud, blender::bke::GeometryOwnershipType::ReadOnly);
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
}
else {
/* The component was empty, we can also remove it. */
geometry_set.remove<blender::bke::PointCloudComponent>();
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
}
return pointcloud;
}
void BKE_pointcloud_data_update(Depsgraph *depsgraph, Scene *scene, Object *object)
{
/* Free any evaluated data and restore original data. */
BKE_object_free_derived_caches(object);
/* Evaluate modifiers. */
PointCloud *pointcloud = static_cast<PointCloud *>(object->data);
blender::bke::GeometrySet geometry_set = blender::bke::GeometrySet::from_pointcloud(
pointcloud, blender::bke::GeometryOwnershipType::ReadOnly);
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
pointcloud_evaluate_modifiers(depsgraph, scene, object, geometry_set);
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
PointCloud *pointcloud_eval = take_pointcloud_ownership_from_geometry_set(geometry_set);
/* If the geometry set did not contain a point cloud, we still create an empty one. */
if (pointcloud_eval == nullptr) {
pointcloud_eval = BKE_pointcloud_new_nomain(0);
}
/* Assign evaluated object. */
Geometry Nodes: support evaluating mesh object to geometry set This implements the design proposed in T83357. The goal is to allow the geometry nodes modifier on mesh objects to output instances and potentially other geometry types. Both problems are tackled by allowing mesh objects to evaluate to a geometry set, instead of just a single mesh id data block. The geometry set can contain a mesh but also other data like instances and a point cloud. I can't say that I'm sure that this commit won't introduce bugs. Mainly the temporary object creation during rendering seems a bit brittle. BUT, we can be reasonably sure that this commit will not introduce regressions (at least not ones, that are hard to fix). This is because the code has been written in a way that minimizes changes for existing functionality. Given that we intend to hide the point cloud object for the next release, we won't even have to worry about temporary object creation for now. An important part of the technical design is to make sure that `ObjectRuntime->data_eval` contains the same data before and after this patch. This helps to make sure, that existing code paths are impacted as little as possible. Instead of fully replacing `data_eval`, there is `geometry_set_eval`, which contains all the geometry components an object evaluated to (including the data referenced by `data_eval`). For now, not much code has to be aware of `geometry_set_eval`. Mainly the depsgraph object iterator and the instances system have to know about it. Reviewers: brecht Differential Revision: https://developer.blender.org/D9851
2020-12-15 12:42:10 +01:00
const bool eval_is_owned = pointcloud_eval != pointcloud;
BKE_object_eval_assign_data(object, &pointcloud_eval->id, eval_is_owned);
object->runtime->geometry_set_eval = new blender::bke::GeometrySet(std::move(geometry_set));
}
Geometry: Cache bounds min and max, share between data-blocks Bounding box calculation can be a large in some situations, especially instancing. This patch caches the min and max of the bounding box in runtime data of meshes, point clouds, and curves, implementing part of T96968. Bounds are now calculated lazily-- only after they are tagged dirty. Also, cached bounds are also shared when copying geometry data-blocks that have equivalent data. When bounds are calculated on an evaluated data-block, they are also accessible on the original, and the next evaluated ID will also share them. A geometry will stop sharing bounds as soon as its positions (or radii) are changed. Just caching the bounds gave a 2-3x speedup with thousands of mesh geometry instances in the viewport. Sharing the bounds can eliminate recalculations entirely in cases like copying meshes in geometry nodes or the selection paint brush in curves sculpt mode, which causes a reevaluation but doesn't change the positions. **Implementation** The sharing is achieved with a `shared_ptr` that points to a cache mutex (from D16419) and the cached bounds data. When geometries are copied, the bounds are shared by default, and only "un-shared" when the bounds are tagged dirty. Point clouds have a new runtime struct to store this data. Functions for tagging the data dirty are improved for added for point clouds and improved for curves. A missing tag has also been fixed for mesh sculpt mode. **Future** There are further improvements which can be worked on next - Apply changes to volume objects and other types where it makes sense - Continue cleanup changes described in T96968 - Apply shared cache design to more expensive data like triangulation or normals Differential Revision: https://developer.blender.org/D16204
2022-11-15 13:46:55 -06:00
void PointCloud::tag_positions_changed()
{
this->runtime->bounds_cache.tag_dirty();
}
void PointCloud::tag_radii_changed()
{
this->runtime->bounds_cache.tag_dirty();
}
/* Draw Cache */
void (*BKE_pointcloud_batch_cache_dirty_tag_cb)(PointCloud *pointcloud, int mode) = nullptr;
void (*BKE_pointcloud_batch_cache_free_cb)(PointCloud *pointcloud) = nullptr;
void BKE_pointcloud_batch_cache_dirty_tag(PointCloud *pointcloud, int mode)
{
if (pointcloud->batch_cache) {
BKE_pointcloud_batch_cache_dirty_tag_cb(pointcloud, mode);
}
}
void BKE_pointcloud_batch_cache_free(PointCloud *pointcloud)
{
if (pointcloud->batch_cache) {
BKE_pointcloud_batch_cache_free_cb(pointcloud);
}
}
namespace blender::bke {
PointCloud *pointcloud_new_no_attributes(int totpoint)
{
PointCloud *pointcloud = BKE_pointcloud_new_nomain(0);
pointcloud->totpoint = totpoint;
CustomData_free_layer_named(&pointcloud->pdata, "position", 0);
return pointcloud;
}
} // namespace blender::bke