git.blender.org/blender.git - Unnamed repository; edit this file 'description' to name the repository.

Age	Commit message (Collapse)	Author
2022-08-30	Fix: Build error on windows	Hans Goudey

2022-08-30	Fix build error from missing include	Hans Goudey

2022-08-30	Geometry Nodes: Use separate field context for each geometry type	Hans Goudey
	Using the same `GeometryComponentFieldContext` for all situations, even when only one geometry type is supported is misleading, and mixes too many different abstraction levels into code that could be simpler. With the attribute API moved out of geometry components recently, the "component" system is just getting in the way here. This commit adds specific field contexts for geometry types: meshes, curves, point clouds, and instances. There are also separate field input helper classes, to help reduce boilerplate for fields that only support specific geometry types. Another benefit of this change is that it separates geometry components from fields, which makes it easier to see the purpose of the two concepts, and how they relate. Because we want to be able to evaluate a field on just `CurvesGeometry` rather than the full `Curves` data-block, the generic "geometry context" had to be changed to avoid using `GeometryComponent`, since there is no corresponding geometry component type. The resulting void pointer is ugly, but only turns up in three places in practice. When Apple clang supports `std::variant`, that could be used instead. Differential Revision: https://developer.blender.org/D15519
2022-06-01	Cleanup: remove redundant const qualifiers for scalar & enum types	Campbell Barton

2022-06-01	Cleanup: use 'e' prefix for enum types	Campbell Barton
	- CustomDataType -> eCustomDataType - CustomDataMask -> eCustomDataMask - AttributeDomain -> eAttrDomain - NamedAttributeUsage -> eNamedAttrUsage
2022-05-05	Cleanup: Move curve length field input to blenkernel	Hans Goudey
	To use in the geometry module when the resample curves code is moved there (T97448).
2022-04-01	Cleanup: Move geometry set fields to a separate header	Hans Goudey
	This commit moves declarations that depend on `FN_field.hh` out of `BKE_geometry_set.hh` into `BKE_geometry_fields.hh`. This helps to reduce the number of areas that need to depend on the functions module, which recently came in in review of D11591. In the future we may have a library of standard field inputs in order to make composing algorithms easier, so it makes sense to have a header that could contain them and some basic related utilities relating the concepts of geometry and fields. Reducing use of unnecessary headers may also reduce compilation time. Differential Revision: https://developer.blender.org/D14517