tmaq
/
tornavis
1
0
Fork 0
Code Issues 2 Pull Requests 29 Packages Projects 24 Releases Wiki Activity
tornavis/source/blender/functions/FN_multi_function_params.hh

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

274 lines
9.6 KiB
C++
Raw Normal View History

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
/*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*/
#pragma once
/** \file
* \ingroup fn
*
* This file provides an MFParams and MFParamsBuilder structure.
*
* `MFParamsBuilder` is used by a function caller to be prepare all parameters that are passed into
* the function. `MFParams` is then used inside the called function to access the parameters.
*/
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
#include "BLI_resource_collector.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
#include "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
#include "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
#include "FN_multi_function_signature.hh"
Cleanup: use nested namespaces
2020-07-03 14:25:20 +02:00
namespace blender::fn {
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
class MFParamsBuilder {
private:
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
ResourceCollector resources_;
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
const MFSignature *signature_;
Refactor: Update integer type usage This updates the usage of integer types in code I wrote according to our new style guides. Major changes: * Use signed instead of unsigned integers in many places. * C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`). * Hash values for C++ containers are 64 bit wide now (instead of 32 bit). I do hope that I broke no builds, but it is quite likely that some compiler reports slightly different errors. Please let me know when there are any errors. If the fix is small, feel free to commit it yourself. I compiled successfully on linux with gcc and on windows.
2020-07-20 12:16:20 +02:00
int64_t min_array_size_;
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
Vector<const GVArray *> virtual_arrays_;
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
Vector<GMutableSpan> mutable_spans_;
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
Vector<const GVVectorArray *> virtual_vector_arrays_;
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
Vector<GVectorArray *> vector_arrays_;
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
friend class MFParams;
public:
Refactor: Update integer type usage This updates the usage of integer types in code I wrote according to our new style guides. Major changes: * Use signed instead of unsigned integers in many places. * C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`). * Hash values for C++ containers are 64 bit wide now (instead of 32 bit). I do hope that I broke no builds, but it is quite likely that some compiler reports slightly different errors. Please let me know when there are any errors. If the fix is small, feel free to commit it yourself. I compiled successfully on linux with gcc and on windows.
2020-07-20 12:16:20 +02:00
MFParamsBuilder(const MFSignature &signature, int64_t min_array_size)
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
: signature_(&signature), min_array_size_(min_array_size)
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
{
}
Refactor: Update integer type usage This updates the usage of integer types in code I wrote according to our new style guides. Major changes: * Use signed instead of unsigned integers in many places. * C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`). * Hash values for C++ containers are 64 bit wide now (instead of 32 bit). I do hope that I broke no builds, but it is quite likely that some compiler reports slightly different errors. Please let me know when there are any errors. If the fix is small, feel free to commit it yourself. I compiled successfully on linux with gcc and on windows.
2020-07-20 12:16:20 +02:00
MFParamsBuilder(const class MultiFunction &fn, int64_t min_array_size);
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
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
template<typename T> void add_readonly_single_input(const T *value, StringRef expected_name = "")
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
{
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
this->add_readonly_single_input(resources_.construct<GVArrayForSingleValueRef>(
__func__, CPPType::get<T>(), min_array_size_, value),
expected_name);
}
void add_readonly_single_input(const GSpan span, StringRef expected_name = "")
{
this->add_readonly_single_input(resources_.construct<GVArrayForGSpan>(__func__, span),
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
expected_name);
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
}
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
void add_readonly_single_input(const GVArray &ref, StringRef expected_name = "")
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
{
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
this->assert_current_param_type(MFParamType::ForSingleInput(ref.type()), expected_name);
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
BLI_assert(ref.size() >= min_array_size_);
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
virtual_arrays_.append(&ref);
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
}
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
void add_readonly_vector_input(const GVectorArray &vector_array, StringRef expected_name = "")
{
this->add_readonly_vector_input(
resources_.construct<GVVectorArrayForGVectorArray>(__func__, vector_array), expected_name);
}
void add_readonly_vector_input(const GVVectorArray &ref, StringRef expected_name = "")
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
{
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
this->assert_current_param_type(MFParamType::ForVectorInput(ref.type()), expected_name);
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
BLI_assert(ref.size() >= min_array_size_);
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
virtual_vector_arrays_.append(&ref);
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
}
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
template<typename T> void add_uninitialized_single_output(T *value, StringRef expected_name = "")
Particles: initial object socket and emitter node support Object sockets work now, but only the new Object Transforms and the Particle Mesh Emitter node use it. The emitter does not actually use the mesh surface yet. Instead, new particles are just emitted around the origin of the object. Internally, handles to object data blocks are passed around in the network, instead of raw object pointers. Using handles has a couple of benefits: * The caller of the function has control over which handles can be resolved and therefore limit access to specific data. The set of data blocks that is accessed by a node tree should be known statically. This is necessary for a proper integration with the dependency graph. * When the pointer to an object changes (e.g. after restarting Blender), all handles are still valid. * When an object is deleted, the handle is invalidated without causing crashes. * The handle is just an integer that can be stored per particle and can be cached easily. The mapping between handles and their corresponding data blocks is stored in the Simulation data block.
2020-07-21 17:20:05 +02:00
{
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
this->add_uninitialized_single_output(GMutableSpan(CPPType::get<T>(), value, 1),
expected_name);
Particles: initial object socket and emitter node support Object sockets work now, but only the new Object Transforms and the Particle Mesh Emitter node use it. The emitter does not actually use the mesh surface yet. Instead, new particles are just emitted around the origin of the object. Internally, handles to object data blocks are passed around in the network, instead of raw object pointers. Using handles has a couple of benefits: * The caller of the function has control over which handles can be resolved and therefore limit access to specific data. The set of data blocks that is accessed by a node tree should be known statically. This is necessary for a proper integration with the dependency graph. * When the pointer to an object changes (e.g. after restarting Blender), all handles are still valid. * When an object is deleted, the handle is invalidated without causing crashes. * The handle is just an integer that can be stored per particle and can be cached easily. The mapping between handles and their corresponding data blocks is stored in the Simulation data block.
2020-07-21 17:20:05 +02:00
}
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
void add_uninitialized_single_output(GMutableSpan ref, StringRef expected_name = "")
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
{
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
this->assert_current_param_type(MFParamType::ForSingleOutput(ref.type()), expected_name);
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
BLI_assert(ref.size() >= min_array_size_);
mutable_spans_.append(ref);
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
}
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
void add_vector_output(GVectorArray &vector_array, StringRef expected_name = "")
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
{
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
this->assert_current_param_type(MFParamType::ForVectorOutput(vector_array.type()),
expected_name);
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
BLI_assert(vector_array.size() >= min_array_size_);
vector_arrays_.append(&vector_array);
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
}
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
void add_single_mutable(GMutableSpan ref, StringRef expected_name = "")
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
{
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
this->assert_current_param_type(MFParamType::ForMutableSingle(ref.type()), expected_name);
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
BLI_assert(ref.size() >= min_array_size_);
mutable_spans_.append(ref);
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
}
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
void add_vector_mutable(GVectorArray &vector_array, StringRef expected_name = "")
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
{
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
this->assert_current_param_type(MFParamType::ForMutableVector(vector_array.type()),
expected_name);
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
BLI_assert(vector_array.size() >= min_array_size_);
vector_arrays_.append(&vector_array);
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
}
Refactor: Update integer type usage This updates the usage of integer types in code I wrote according to our new style guides. Major changes: * Use signed instead of unsigned integers in many places. * C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`). * Hash values for C++ containers are 64 bit wide now (instead of 32 bit). I do hope that I broke no builds, but it is quite likely that some compiler reports slightly different errors. Please let me know when there are any errors. If the fix is small, feel free to commit it yourself. I compiled successfully on linux with gcc and on windows.
2020-07-20 12:16:20 +02:00
GMutableSpan computed_array(int param_index)
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
{
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
BLI_assert(ELEM(signature_->param_types[param_index].category(),
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
MFParamType::SingleOutput,
MFParamType::SingleMutable));
Refactor: Update integer type usage This updates the usage of integer types in code I wrote according to our new style guides. Major changes: * Use signed instead of unsigned integers in many places. * C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`). * Hash values for C++ containers are 64 bit wide now (instead of 32 bit). I do hope that I broke no builds, but it is quite likely that some compiler reports slightly different errors. Please let me know when there are any errors. If the fix is small, feel free to commit it yourself. I compiled successfully on linux with gcc and on windows.
2020-07-20 12:16:20 +02:00
int data_index = signature_->data_index(param_index);
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
return mutable_spans_[data_index];
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
}
Refactor: Update integer type usage This updates the usage of integer types in code I wrote according to our new style guides. Major changes: * Use signed instead of unsigned integers in many places. * C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`). * Hash values for C++ containers are 64 bit wide now (instead of 32 bit). I do hope that I broke no builds, but it is quite likely that some compiler reports slightly different errors. Please let me know when there are any errors. If the fix is small, feel free to commit it yourself. I compiled successfully on linux with gcc and on windows.
2020-07-20 12:16:20 +02:00
GVectorArray &computed_vector_array(int param_index)
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
{
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
BLI_assert(ELEM(signature_->param_types[param_index].category(),
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
MFParamType::VectorOutput,
MFParamType::VectorMutable));
Refactor: Update integer type usage This updates the usage of integer types in code I wrote according to our new style guides. Major changes: * Use signed instead of unsigned integers in many places. * C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`). * Hash values for C++ containers are 64 bit wide now (instead of 32 bit). I do hope that I broke no builds, but it is quite likely that some compiler reports slightly different errors. Please let me know when there are any errors. If the fix is small, feel free to commit it yourself. I compiled successfully on linux with gcc and on windows.
2020-07-20 12:16:20 +02:00
int data_index = signature_->data_index(param_index);
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
return *vector_arrays_[data_index];
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
}
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
ResourceCollector &resources()
{
return resources_;
}
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
private:
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
void assert_current_param_type(MFParamType param_type, StringRef expected_name = "")
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
{
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
UNUSED_VARS_NDEBUG(param_type, expected_name);
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
#ifdef DEBUG
Refactor: Update integer type usage This updates the usage of integer types in code I wrote according to our new style guides. Major changes: * Use signed instead of unsigned integers in many places. * C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`). * Hash values for C++ containers are 64 bit wide now (instead of 32 bit). I do hope that I broke no builds, but it is quite likely that some compiler reports slightly different errors. Please let me know when there are any errors. If the fix is small, feel free to commit it yourself. I compiled successfully on linux with gcc and on windows.
2020-07-20 12:16:20 +02:00
int param_index = this->current_param_index();
Particles: improve mesh emitter Particles are now emitted from vertices of the mesh.
2020-07-23 17:57:11 +02:00
if (expected_name != "") {
StringRef actual_name = signature_->param_names[param_index];
BLI_assert(actual_name == expected_name);
}
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
MFParamType expected_type = signature_->param_types[param_index];
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
BLI_assert(expected_type == param_type);
#endif
}
Refactor: Update integer type usage This updates the usage of integer types in code I wrote according to our new style guides. Major changes: * Use signed instead of unsigned integers in many places. * C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`). * Hash values for C++ containers are 64 bit wide now (instead of 32 bit). I do hope that I broke no builds, but it is quite likely that some compiler reports slightly different errors. Please let me know when there are any errors. If the fix is small, feel free to commit it yourself. I compiled successfully on linux with gcc and on windows.
2020-07-20 12:16:20 +02:00
int current_param_index() const
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
{
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
return virtual_arrays_.size() + mutable_spans_.size() + virtual_vector_arrays_.size() +
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
vector_arrays_.size();
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
}
};
class MFParams {
private:
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
MFParamsBuilder *builder_;
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
public:
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
MFParams(MFParamsBuilder &builder) : builder_(&builder)
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
{
}
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
template<typename T> const VArray<T> &readonly_single_input(int param_index, StringRef name = "")
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
{
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
const GVArray &array = this->readonly_single_input(param_index, name);
return builder_->resources_.construct<VArrayForGVArray<T>>(__func__, array);
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
}
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
const GVArray &readonly_single_input(int param_index, StringRef name = "")
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
{
this->assert_correct_param(param_index, name, MFParamType::SingleInput);
Refactor: Update integer type usage This updates the usage of integer types in code I wrote according to our new style guides. Major changes: * Use signed instead of unsigned integers in many places. * C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`). * Hash values for C++ containers are 64 bit wide now (instead of 32 bit). I do hope that I broke no builds, but it is quite likely that some compiler reports slightly different errors. Please let me know when there are any errors. If the fix is small, feel free to commit it yourself. I compiled successfully on linux with gcc and on windows.
2020-07-20 12:16:20 +02:00
int data_index = builder_->signature_->data_index(param_index);
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
return *builder_->virtual_arrays_[data_index];
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
}
template<typename T>
Refactor: Update integer type usage This updates the usage of integer types in code I wrote according to our new style guides. Major changes: * Use signed instead of unsigned integers in many places. * C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`). * Hash values for C++ containers are 64 bit wide now (instead of 32 bit). I do hope that I broke no builds, but it is quite likely that some compiler reports slightly different errors. Please let me know when there are any errors. If the fix is small, feel free to commit it yourself. I compiled successfully on linux with gcc and on windows.
2020-07-20 12:16:20 +02:00
MutableSpan<T> uninitialized_single_output(int param_index, StringRef name = "")
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
{
return this->uninitialized_single_output(param_index, name).typed<T>();
}
Refactor: Update integer type usage This updates the usage of integer types in code I wrote according to our new style guides. Major changes: * Use signed instead of unsigned integers in many places. * C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`). * Hash values for C++ containers are 64 bit wide now (instead of 32 bit). I do hope that I broke no builds, but it is quite likely that some compiler reports slightly different errors. Please let me know when there are any errors. If the fix is small, feel free to commit it yourself. I compiled successfully on linux with gcc and on windows.
2020-07-20 12:16:20 +02:00
GMutableSpan uninitialized_single_output(int param_index, StringRef name = "")
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
{
this->assert_correct_param(param_index, name, MFParamType::SingleOutput);
Refactor: Update integer type usage This updates the usage of integer types in code I wrote according to our new style guides. Major changes: * Use signed instead of unsigned integers in many places. * C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`). * Hash values for C++ containers are 64 bit wide now (instead of 32 bit). I do hope that I broke no builds, but it is quite likely that some compiler reports slightly different errors. Please let me know when there are any errors. If the fix is small, feel free to commit it yourself. I compiled successfully on linux with gcc and on windows.
2020-07-20 12:16:20 +02:00
int data_index = builder_->signature_->data_index(param_index);
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
return builder_->mutable_spans_[data_index];
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
}
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
template<typename T>
const VVectorArray<T> &readonly_vector_input(int param_index, StringRef name = "")
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
{
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
const GVVectorArray &vector_array = this->readonly_vector_input(param_index, name);
return builder_->resources_.construct<VVectorArrayForGVVectorArray<T>>(__func__, vector_array);
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
}
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
const GVVectorArray &readonly_vector_input(int param_index, StringRef name = "")
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
{
this->assert_correct_param(param_index, name, MFParamType::VectorInput);
Refactor: Update integer type usage This updates the usage of integer types in code I wrote according to our new style guides. Major changes: * Use signed instead of unsigned integers in many places. * C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`). * Hash values for C++ containers are 64 bit wide now (instead of 32 bit). I do hope that I broke no builds, but it is quite likely that some compiler reports slightly different errors. Please let me know when there are any errors. If the fix is small, feel free to commit it yourself. I compiled successfully on linux with gcc and on windows.
2020-07-20 12:16:20 +02:00
int data_index = builder_->signature_->data_index(param_index);
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
return *builder_->virtual_vector_arrays_[data_index];
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
}
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
template<typename T>
GVectorArray_TypedMutableRef<T> vector_output(int param_index, StringRef name = "")
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
{
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
return {this->vector_output(param_index, name)};
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
}
Refactor: Update integer type usage This updates the usage of integer types in code I wrote according to our new style guides. Major changes: * Use signed instead of unsigned integers in many places. * C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`). * Hash values for C++ containers are 64 bit wide now (instead of 32 bit). I do hope that I broke no builds, but it is quite likely that some compiler reports slightly different errors. Please let me know when there are any errors. If the fix is small, feel free to commit it yourself. I compiled successfully on linux with gcc and on windows.
2020-07-20 12:16:20 +02:00
GVectorArray &vector_output(int param_index, StringRef name = "")
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
{
this->assert_correct_param(param_index, name, MFParamType::VectorOutput);
Refactor: Update integer type usage This updates the usage of integer types in code I wrote according to our new style guides. Major changes: * Use signed instead of unsigned integers in many places. * C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`). * Hash values for C++ containers are 64 bit wide now (instead of 32 bit). I do hope that I broke no builds, but it is quite likely that some compiler reports slightly different errors. Please let me know when there are any errors. If the fix is small, feel free to commit it yourself. I compiled successfully on linux with gcc and on windows.
2020-07-20 12:16:20 +02:00
int data_index = builder_->signature_->data_index(param_index);
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
return *builder_->vector_arrays_[data_index];
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
}
Refactor: Update integer type usage This updates the usage of integer types in code I wrote according to our new style guides. Major changes: * Use signed instead of unsigned integers in many places. * C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`). * Hash values for C++ containers are 64 bit wide now (instead of 32 bit). I do hope that I broke no builds, but it is quite likely that some compiler reports slightly different errors. Please let me know when there are any errors. If the fix is small, feel free to commit it yourself. I compiled successfully on linux with gcc and on windows.
2020-07-20 12:16:20 +02:00
template<typename T> MutableSpan<T> single_mutable(int param_index, StringRef name = "")
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
{
return this->single_mutable(param_index, name).typed<T>();
}
Refactor: Update integer type usage This updates the usage of integer types in code I wrote according to our new style guides. Major changes: * Use signed instead of unsigned integers in many places. * C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`). * Hash values for C++ containers are 64 bit wide now (instead of 32 bit). I do hope that I broke no builds, but it is quite likely that some compiler reports slightly different errors. Please let me know when there are any errors. If the fix is small, feel free to commit it yourself. I compiled successfully on linux with gcc and on windows.
2020-07-20 12:16:20 +02:00
GMutableSpan single_mutable(int param_index, StringRef name = "")
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
{
this->assert_correct_param(param_index, name, MFParamType::SingleMutable);
Refactor: Update integer type usage This updates the usage of integer types in code I wrote according to our new style guides. Major changes: * Use signed instead of unsigned integers in many places. * C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`). * Hash values for C++ containers are 64 bit wide now (instead of 32 bit). I do hope that I broke no builds, but it is quite likely that some compiler reports slightly different errors. Please let me know when there are any errors. If the fix is small, feel free to commit it yourself. I compiled successfully on linux with gcc and on windows.
2020-07-20 12:16:20 +02:00
int data_index = builder_->signature_->data_index(param_index);
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
return builder_->mutable_spans_[data_index];
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
}
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
template<typename T>
GVectorArray_TypedMutableRef<T> vector_mutable(int param_index, StringRef name = "")
Functions: Various improvements to the spans and generic data structures Most of this code is covered by unit tests.
2020-06-22 15:48:08 +02:00
{
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
return {this->vector_mutable(param_index, name)};
Functions: Various improvements to the spans and generic data structures Most of this code is covered by unit tests.
2020-06-22 15:48:08 +02:00
}
Refactor: Update integer type usage This updates the usage of integer types in code I wrote according to our new style guides. Major changes: * Use signed instead of unsigned integers in many places. * C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`). * Hash values for C++ containers are 64 bit wide now (instead of 32 bit). I do hope that I broke no builds, but it is quite likely that some compiler reports slightly different errors. Please let me know when there are any errors. If the fix is small, feel free to commit it yourself. I compiled successfully on linux with gcc and on windows.
2020-07-20 12:16:20 +02:00
GVectorArray &vector_mutable(int param_index, StringRef name = "")
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
{
this->assert_correct_param(param_index, name, MFParamType::VectorMutable);
Refactor: Update integer type usage This updates the usage of integer types in code I wrote according to our new style guides. Major changes: * Use signed instead of unsigned integers in many places. * C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`). * Hash values for C++ containers are 64 bit wide now (instead of 32 bit). I do hope that I broke no builds, but it is quite likely that some compiler reports slightly different errors. Please let me know when there are any errors. If the fix is small, feel free to commit it yourself. I compiled successfully on linux with gcc and on windows.
2020-07-20 12:16:20 +02:00
int data_index = builder_->signature_->data_index(param_index);
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
return *builder_->vector_arrays_[data_index];
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
}
private:
Refactor: Update integer type usage This updates the usage of integer types in code I wrote according to our new style guides. Major changes: * Use signed instead of unsigned integers in many places. * C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`). * Hash values for C++ containers are 64 bit wide now (instead of 32 bit). I do hope that I broke no builds, but it is quite likely that some compiler reports slightly different errors. Please let me know when there are any errors. If the fix is small, feel free to commit it yourself. I compiled successfully on linux with gcc and on windows.
2020-07-20 12:16:20 +02:00
void assert_correct_param(int param_index, StringRef name, MFParamType param_type)
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
{
UNUSED_VARS_NDEBUG(param_index, name, param_type);
#ifdef DEBUG
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
BLI_assert(builder_->signature_->param_types[param_index] == param_type);
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
if (name.size() > 0) {
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
BLI_assert(builder_->signature_->param_names[param_index] == name);
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
}
#endif
}
Refactor: Update integer type usage This updates the usage of integer types in code I wrote according to our new style guides. Major changes: * Use signed instead of unsigned integers in many places. * C++ containers in blenlib use `int64_t` for size and indices now (instead of `uint`). * Hash values for C++ containers are 64 bit wide now (instead of 32 bit). I do hope that I broke no builds, but it is quite likely that some compiler reports slightly different errors. Please let me know when there are any errors. If the fix is small, feel free to commit it yourself. I compiled successfully on linux with gcc and on windows.
2020-07-20 12:16:20 +02:00
void assert_correct_param(int param_index, StringRef name, MFParamType::Category category)
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
{
UNUSED_VARS_NDEBUG(param_index, name, category);
#ifdef DEBUG
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
BLI_assert(builder_->signature_->param_types[param_index].category() == category);
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
if (name.size() > 0) {
Cleanup: use trailing underscore for non-public data members
2020-07-03 14:20:42 +02:00
BLI_assert(builder_->signature_->param_names[param_index] == name);
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
}
#endif
}
};
Cleanup: use nested namespaces
2020-07-03 14:25:20 +02:00
} // namespace blender::fn