Change Details

Currently there are two attribute APIs. The first, defined in `BKE_attribute.h` is accessible from RNA and C code, The second is implemented with `GeometryComponent`, accessible in C++ code. The second is widely used, but only being accessible through the geometry set API makes it awkward to use, and even impossible for types that don't correspond directly to a geometry component type like `CurvesGeometry` (or even `BMesh`). This patch adds a new attribute API, designed to eventually replace the other two. The basic structure provides the user with a `AttributeAccessor` class, which has a pointer to data and a pointer to an implementation of functions that access and change attributes. This implementation satisfies a few requirements. - **Const correctness**: Correctness is non-trivial. Attributes cannot be changed without mutable data, and one cannot break it by simply copying the accessor. - **Stack storage**: The accessor type is small enough to be stored on the stack and can be returned by value. - **Avoid complex inheritance**: One could imagine all geometry types inheriting from some "Attribute provider base class". However, this doesn't work well with the C-like way these types are used elsewhere in Blender. In the end, attribute access is still implemented with the pattern of "providers", defined in the geometry component files. Now these can be defined elsewhere as well though.

Currently there are two attribute APIs. The first, defined in `BKE_attribute.h` is accessible from RNA and C code, The second is implemented with `GeometryComponent`, accessible in C++ code. The second is widely used, but only being accessible through the geometry set API makes it awkward to use, and even impossible for types that don't correspond directly to a geometry component type like `CurvesGeometry` (or even `BMesh`). This patch adds a new attribute API, designed to replace the `GeometryComponent` attribute API now, and to eventually replace the other one. The basic structure provides the user with an `AttributeAccessor` class, which has a pointer to data and a pointer to an implementation of functions that access and change attributes. This implementation satisfies a few requirements. - **Const correctness**: Correctness is non-trivial. Attributes cannot be changed without mutable data, and one cannot break it by simply copying the accessor. - **Stack storage**: The accessor type is small enough to be stored on the stack and can be returned by value. - **Avoid complex inheritance**: One could imagine all geometry types inheriting from some "Attribute provider base class". However, this doesn't work well with the C-like way these types are used elsewhere in Blender. In the end, attribute access is still implemented with the pattern of "providers", defined in the geometry component files. Now these can be defined elsewhere as well though.

Currently there are two attribute APIs. The first, defined in `BKE_attribute.h` is accessible from RNA and C code, The second is implemented with `GeometryComponent`, accessible in C++ code. The second is widely used, but only being accessible through the geometry set API makes it awkward to use, and even impossible for types that don't correspond directly to a geometry component type like `CurvesGeometry` (or even `BMesh`). This patch adds a new attribute API, designed to eventually replace the other two. The basic structure provides the user with a `A`GeometryComponent` attributeAccessor` classe API now, and to eventually replace the other one. The basic structure provides the user with an `AttributeAccessor` class, which has a pointer to data and a pointer to an implementation of functions that access and change attributes. This implementation satisfies a few requirements. - **Const correctness**: Correctness is non-trivial. Attributes cannot be changed without mutable data, and one cannot break it by simply copying the accessor. - **Stack storage**: The accessor type is small enough to be stored on the stack and can be returned by value. - **Avoid complex inheritance**: One could imagine all geometry types inheriting from some "Attribute provider base class". However, this doesn't work well with the C-like way these types are used elsewhere in Blender. In the end, attribute access is still implemented with the pattern of "providers", defined in the geometry component files. Now these can be defined elsewhere as well though.