With the ultimate goal of simplifying drawing and evaluation,
this patch makes the following changes and removes code:
- Use `Mesh` instead of `DispList` for evaluated basis metaballs.
- Remove all `DispList` drawing code, which is now unused.
- Simplify code that converts evaluated metaballs to meshes.
- Store the evaluated mesh in the evaluated geometry set.
This has the following indirect benefits:
- Evaluated meshes from metaball objects can be used in geometry nodes.
- Renderers can ignore evaluated metaball objects completely
- Cycles rendering no longer has to convert to mesh from `DispList`.
- We get closer to removing `DispList` completely.
- Optimizations to mesh rendering will also apply to metaball objects.
The vertex normals on the evaluated mesh are technically invalid;
the regular calculation wouldn't reproduce them. Metaball objects
don't support modifiers though, so it shouldn't be a problem.
Eventually we can support per-vertex custom normals (T93551).
Differential Revision: https://developer.blender.org/D14593
Need to update relations when modifiers are added or removed
since those create nodes in the dependency graph.
Added an assert statement to point at possible culprit so
that issues can be fixed more quickly.
The issue was that geometry nodes was run on the original curves,
and set a pointer to an evaluated material id on it. The fix is to not
mix up original and evaluated data by making sure that geometry nodes
does not modify the original data.
Currently, there are two attribute API. The first, defined in `BKE_attribute.h` is
accessible from RNA and C code. The second is implemented with `GeometryComponent`
and is only accessible in C++ code. The second is widely used, but only being
accessible through the `GeometrySet` API makes it awkward to use, and even impossible
for types that don't correspond directly to a geometry component like `CurvesGeometry`.
This patch adds a new attribute API, designed to replace the `GeometryComponent`
attribute API now, and to eventually replace or be the basis of the other one.
The basic idea is that there is an `AttributeAccessor` class that allows code to
interact with a set of attributes owned by some geometry. The accessor itself has
no ownership. `AttributeAccessor` is a simple type that can be passed around by
value. That makes it easy to return it from functions and to store it in containers.
For const-correctness, there is also a `MutableAttributeAccessor` that allows
changing individual and can add or remove attributes.
Currently, `AttributeAccessor` is composed of two pointers. The first is a pointer
to the owner of the attribute data. The second is a pointer to a struct with
function pointers, that is similar to a virtual function table. The functions
know how to access attributes on the owner.
The actual attribute access for geometries is still implemented with the `AttributeProvider`
pattern, which makes it easy to support different sources of attributes on a
geometry and simplifies dealing with built-in attributes.
There are different ways to get an attribute accessor for a geometry:
* `GeometryComponent.attributes()`
* `CurvesGeometry.attributes()`
* `bke::mesh_attributes(const Mesh &)`
* `bke::pointcloud_attributes(const PointCloud &)`
All of these also have a `_for_write` variant that returns a `MutabelAttributeAccessor`.
Differential Revision: https://developer.blender.org/D15280
The operator assumed it was called on a mesh object, which has
mostly been the case because of lack of support for other object
types, but the new curves object is supported, which is the situation
in the report.
Differential Revision: https://developer.blender.org/D15063
Regression in [0] which is useful when applying modifiers as a shape-key
but not when applying modifiers which keeps the existing shape-keys.
[0]: 65c5ebf577
Support merging UV's that share the same vertex and are very close when
applying modifiers.
This is needed to prevent UV's becoming "detached" which can happen when
applying the subdivision surface modifier.
This regression was caused by [0] which removed selection threshold for
nearby coordinates. While restoring the UV selection threshold could be
done - some selection operations that walk around connected UV fans
wouldn't behave in a deterministic way (such as select shortest path).
There are also other cases where UV's may be compared without a
threshold such as tangent calculation and exporters which have their own
logic to handling UV's.
Also resolves T86896, T89903.
[0]: b88dd3b8e7
Reviewed By: sergey
Ref D14841
This commit adds support for the curves object to the apply modifier
operator. A warning is added when the evaluated result of the modifier
doesn't contain any curves data.
Differential Revision: https://developer.blender.org/D14730
