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
ccb372d17c2db88141dc4511550daac024121eb9
blender-archive/source/blender/functions/CMakeLists.txt

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

80 lines
2.2 KiB
CMake
Raw Normal View History

Functions: Run-time type system and index mask This adds a new `CPPType` that encapsulates information about how to handle instances of a specific data type. This is necessary for the function evaluation system, which will be used to evaluate most of the particle node trees. Furthermore, this adds an `IndexMask` class which offers a surprisingly useful abstraction over an array containing unsigned integers. It makes two assumptions about the underlying integer array: * The integers are in ascending order. * There are no duplicates. `IndexMask` will be used to "select" certain particles that will be processed in a data-oriented way. Sometimes, operations don't have to be applied to all particles, but only some, those that are in the indexed by the `IndexMask`. The two limitations imposed by an `IndexMask` allow for better performance. Reviewers: brecht Differential Revision: https://developer.blender.org/D7957
2020-06-08 17:37:43 +02:00
# ***** BEGIN GPL LICENSE BLOCK *****
#
# 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.
#
# ***** END GPL LICENSE BLOCK *****
set(INC
.
../blenlib
../makesdna
../../../intern/guardedalloc
)
set(INC_SYS
)
set(SRC
intern/cpp_types.cc
Functions: refactor virtual array data structures When a function is executed for many elements (e.g. per point) it is often the case that some parameters are different for every element and other parameters are the same (there are some more less common cases). To simplify writing such functions one can use a "virtual array". This is a data structure that has a value for every index, but might not be stored as an actual array internally. Instead, it might be just a single value or is computed on the fly. There are various tradeoffs involved when using this data structure which are mentioned in `BLI_virtual_array.hh`. It is called "virtual", because it uses inheritance and virtual methods. Furthermore, there is a new virtual vector array data structure, which is an array of vectors. Both these types have corresponding generic variants, which can be used when the data type is not known at compile time. This is typically the case when building a somewhat generic execution system. The function system used these virtual data structures before, but now they are more versatile. I've done this refactor in preparation for the attribute processor and other features of geometry nodes. I moved the typed virtual arrays to blenlib, so that they can be used independent of the function system. One open question for me is whether all the generic data structures (and `CPPType`) should be moved to blenlib as well. They are well isolated and don't really contain any business logic. That can be done later if necessary.
2021-03-21 19:31:24 +01:00
intern/generic_vector_array.cc
intern/generic_virtual_array.cc
intern/generic_virtual_vector_array.cc
Functions: provide dummy multi function Sometimes it is convenient to be able to return a reference to some dummy function.
2020-06-30 18:05:44 +02:00
intern/multi_function.cc
Functions: add generic functions that output constants
2020-07-07 19:34:35 +02:00
intern/multi_function_builder.cc
Functions: Multi Function Network A multi-function network is a graph data structure, where nodes are multi-functions (or dummies) and links represent data flow. New multi-functions can be derived from such a network. For that one just has to specify two sets of sockets in the network that represent the inputs and outputs of the new function. It is possible to do optimizations like constant folding on this data structure, but that is not implemented in this patch yet. In a next step, user generated node trees are converted into a MFNetwork, so that they can be evaluated efficiently for many particles. This patch also includes some tests that cover the majority of the code. However, this seems to be the kind of code that is best tested by some .blend files. Building graph structures in code is possible, but is not easy to understand afterwards. Reviewers: brecht Differential Revision: https://developer.blender.org/D8049
2020-06-23 10:16:14 +02:00
intern/multi_function_network.cc
intern/multi_function_network_evaluation.cc
Functions: add dead node removal and constant folding optimization Those optimizations work on the multi-function network level. Not only will they make the network evaluation faster, but they also simplify the network a lot. That makes it easier to understand the exported dot graph.
2020-07-08 11:18:43 +02:00
intern/multi_function_network_optimization.cc
Functions: Run-time type system and index mask This adds a new `CPPType` that encapsulates information about how to handle instances of a specific data type. This is necessary for the function evaluation system, which will be used to evaluate most of the particle node trees. Furthermore, this adds an `IndexMask` class which offers a surprisingly useful abstraction over an array containing unsigned integers. It makes two assumptions about the underlying integer array: * The integers are in ascending order. * There are no duplicates. `IndexMask` will be used to "select" certain particles that will be processed in a data-oriented way. Sometimes, operations don't have to be applied to all particles, but only some, those that are in the indexed by the `IndexMask`. The two limitations imposed by an `IndexMask` allow for better performance. Reviewers: brecht Differential Revision: https://developer.blender.org/D7957
2020-06-08 17:37:43 +02:00
FN_cpp_type.hh
Functions: move CPPType creation related code to separate header This does not need to be included everywhere, because it is only needed in very few translation units that actually define CPPType's.
2021-03-21 15:33:30 +01:00
FN_cpp_type_make.hh
Functions: add generic pointer class This class represents a pointer whose type is only known at runtime.
2020-12-02 12:59:42 +01:00
FN_generic_pointer.hh
Functions: refactor virtual array data structures When a function is executed for many elements (e.g. per point) it is often the case that some parameters are different for every element and other parameters are the same (there are some more less common cases). To simplify writing such functions one can use a "virtual array". This is a data structure that has a value for every index, but might not be stored as an actual array internally. Instead, it might be just a single value or is computed on the fly. There are various tradeoffs involved when using this data structure which are mentioned in `BLI_virtual_array.hh`. It is called "virtual", because it uses inheritance and virtual methods. Furthermore, there is a new virtual vector array data structure, which is an array of vectors. Both these types have corresponding generic variants, which can be used when the data type is not known at compile time. This is typically the case when building a somewhat generic execution system. The function system used these virtual data structures before, but now they are more versatile. I've done this refactor in preparation for the attribute processor and other features of geometry nodes. I moved the typed virtual arrays to blenlib, so that they can be used independent of the function system. One open question for me is whether all the generic data structures (and `CPPType`) should be moved to blenlib as well. They are well isolated and don't really contain any business logic. That can be done later if necessary.
2021-03-21 19:31:24 +01:00
FN_generic_span.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
FN_generic_value_map.hh
Cleanup: missing CMake headers from source lists
2020-07-16 13:17:31 +10:00
FN_generic_vector_array.hh
Functions: refactor virtual array data structures When a function is executed for many elements (e.g. per point) it is often the case that some parameters are different for every element and other parameters are the same (there are some more less common cases). To simplify writing such functions one can use a "virtual array". This is a data structure that has a value for every index, but might not be stored as an actual array internally. Instead, it might be just a single value or is computed on the fly. There are various tradeoffs involved when using this data structure which are mentioned in `BLI_virtual_array.hh`. It is called "virtual", because it uses inheritance and virtual methods. Furthermore, there is a new virtual vector array data structure, which is an array of vectors. Both these types have corresponding generic variants, which can be used when the data type is not known at compile time. This is typically the case when building a somewhat generic execution system. The function system used these virtual data structures before, but now they are more versatile. I've done this refactor in preparation for the attribute processor and other features of geometry nodes. I moved the typed virtual arrays to blenlib, so that they can be used independent of the function system. One open question for me is whether all the generic data structures (and `CPPType`) should be moved to blenlib as well. They are well isolated and don't really contain any business logic. That can be done later if necessary.
2021-03-21 19:31:24 +01:00
FN_generic_virtual_array.hh
FN_generic_virtual_vector_array.hh
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
FN_multi_function.hh
Functions: add utilities that allow creating some multi-functions with less typing
2020-06-22 15:50:08 +02:00
FN_multi_function_builder.hh
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
FN_multi_function_context.hh
FN_multi_function_data_type.hh
Functions: Multi Function Network A multi-function network is a graph data structure, where nodes are multi-functions (or dummies) and links represent data flow. New multi-functions can be derived from such a network. For that one just has to specify two sets of sockets in the network that represent the inputs and outputs of the new function. It is possible to do optimizations like constant folding on this data structure, but that is not implemented in this patch yet. In a next step, user generated node trees are converted into a MFNetwork, so that they can be evaluated efficiently for many particles. This patch also includes some tests that cover the majority of the code. However, this seems to be the kind of code that is best tested by some .blend files. Building graph structures in code is possible, but is not easy to understand afterwards. Reviewers: brecht Differential Revision: https://developer.blender.org/D8049
2020-06-23 10:16:14 +02:00
FN_multi_function_network.hh
FN_multi_function_network_evaluation.hh
Functions: add dead node removal and constant folding optimization Those optimizations work on the multi-function network level. Not only will they make the network evaluation faster, but they also simplify the network a lot. That makes it easier to understand the exported dot graph.
2020-07-08 11:18:43 +02:00
FN_multi_function_network_optimization.hh
Functions: Multi Function This adds the `MultiFunction` type and some smallish utility types that it uses. A `MultiFunction` encapsulates a function that is optimized for throughput by always processing many elements at once. This is an important part of the new particle system, because it allows us to execute user generated node trees for many particles efficiently. Reviewers: brecht Differential Revision: https://developer.blender.org/D8030
2020-06-16 16:35:57 +02:00
FN_multi_function_param_type.hh
FN_multi_function_params.hh
FN_multi_function_signature.hh
Functions: Run-time type system and index mask This adds a new `CPPType` that encapsulates information about how to handle instances of a specific data type. This is necessary for the function evaluation system, which will be used to evaluate most of the particle node trees. Furthermore, this adds an `IndexMask` class which offers a surprisingly useful abstraction over an array containing unsigned integers. It makes two assumptions about the underlying integer array: * The integers are in ascending order. * There are no duplicates. `IndexMask` will be used to "select" certain particles that will be processed in a data-oriented way. Sometimes, operations don't have to be applied to all particles, but only some, those that are in the indexed by the `IndexMask`. The two limitations imposed by an `IndexMask` allow for better performance. Reviewers: brecht Differential Revision: https://developer.blender.org/D7957
2020-06-08 17:37:43 +02:00
)
set(LIB
bf_blenlib
)
blender_add_lib(bf_functions "${SRC}" "${INC}" "${INC_SYS}" "${LIB}")
Functions: move tests closer to code
2020-07-26 12:19:11 +02:00
if(WITH_GTESTS)
set(TEST_SRC
tests/FN_cpp_type_test.cc
Functions: refactor virtual array data structures When a function is executed for many elements (e.g. per point) it is often the case that some parameters are different for every element and other parameters are the same (there are some more less common cases). To simplify writing such functions one can use a "virtual array". This is a data structure that has a value for every index, but might not be stored as an actual array internally. Instead, it might be just a single value or is computed on the fly. There are various tradeoffs involved when using this data structure which are mentioned in `BLI_virtual_array.hh`. It is called "virtual", because it uses inheritance and virtual methods. Furthermore, there is a new virtual vector array data structure, which is an array of vectors. Both these types have corresponding generic variants, which can be used when the data type is not known at compile time. This is typically the case when building a somewhat generic execution system. The function system used these virtual data structures before, but now they are more versatile. I've done this refactor in preparation for the attribute processor and other features of geometry nodes. I moved the typed virtual arrays to blenlib, so that they can be used independent of the function system. One open question for me is whether all the generic data structures (and `CPPType`) should be moved to blenlib as well. They are well isolated and don't really contain any business logic. That can be done later if necessary.
2021-03-21 19:31:24 +01:00
tests/FN_generic_span_test.cc
Functions: move tests closer to code
2020-07-26 12:19:11 +02:00
tests/FN_generic_vector_array_test.cc
tests/FN_multi_function_network_test.cc
tests/FN_multi_function_test.cc
)
Cleanup: add missing headers to CMake, formatting
2020-09-15 22:50:11 +10:00
set(TEST_LIB
Functions: move tests closer to code
2020-07-26 12:19:11 +02:00
bf_functions
)
include(GTestTesting)
blender_add_test_lib(bf_functions_tests "${TEST_SRC}" "${INC};${TEST_INC}" "${INC_SYS}" "${LIB};${TEST_LIB}")
endif()
Copy Permalink