This commit moves the storage of `bDeformGroup` and the active index
to `Mesh`, `Lattice`, and `bGPdata` instead of `Object`. Utility
functions are added to allow easy access to the vertex groups given
an object or an ID.
As explained in T88951, the list of vertex group names is currently
stored separately per object, even though vertex group data is stored
on the geometry. This tends to complicate code and cause bugs,
especially as geometry is created procedurally and tied less closely
to an object.
The "Copy Vertex Groups to Linked" operator is removed, since they
are stored on the geometry anyway.
This patch leaves the object-level python API for vertex groups in
place. Creating a geometry-level RNA API can be a separate step;
the changes in this commit are invasive enough as it is.
Note that opening a file saved in 3.0 in an earlier version means
the vertex groups will not be available.
Differential Revision: https://developer.blender.org/D11689
Rename:
- EDBM_mesh_free -> EDBM_mesh_free_data
BKE_editmesh_free -> BKE_editmesh_free_data
Since this doesn't free the edit-mesh pointer.
- BKE_editmesh_free_derivedmesh -> BKE_editmesh_free_derived_caches
Since this no longer uses derived-mesh, match naming for the related
object function BKE_object_free_derived_caches.
Also remove `do_tessellate` argument from BKE_editmesh_create,
since the caller can explicitly do this if it's needed,
with the advantage that it can be combined with normal calculation
which is faster on high-poly meshes.
This patch fixes many minor spelling mistakes, all in comments or
console output. Mostly contractions like can't, won't, don't, its/it's,
etc.
Differential Revision: https://developer.blender.org/D11663
Reviewed by Harley Acheson
- BKE_mesh_copy_parameters_for_eval to be used for evaluated meshes only
as it doesn't handle ID user-counts.
- BKE_mesh_copy_parameters is a general function for copying parameters
between meshes.
This patch adds initial curve support to geometry nodes. Currently
there is only one node available, the "Curve to Mesh" node, T87428.
However, the aim of the changes here is larger than just supporting
curve data in nodes-- it also uses the opportunity to add better spline
data structures, intended to replace the existing curve evaluation code.
The curve code in Blender is quite old, and it's generally regarded as
some of the messiest, hardest-to-understand code as well. The classes
in `BKE_spline.hh` aim to be faster, more extensible, and much more
easily understandable. Further explanation can be found in comments in
that file.
Initial builtin spline attributes are supported-- reading and writing
from the `cyclic` and `resolution` attributes works with any of the
attribute nodes. Also, only Z-up normal calculation is implemented
at the moment, and tilts do not apply yet.
**Limitations**
- For now, you must bring curves into the node tree with an "Object
Info" node. Changes to the curve modifier stack will come later.
- Converting to a mesh is necessary to visualize the curve data.
Further progress can be tracked in: T87245
Higher level design document: https://wiki.blender.org/wiki/Modules/Physics_Nodes/Projects/EverythingNodes/CurveNodes
Differential Revision: https://developer.blender.org/D11091
Previously, when a Geometry Nodes modifier outputs a point cloud
(e.g. generated using the Point Distribute node), other modifiers
could not use that data. Now, the point cloud data is converted to
mesh vertices for such modifiers.
Ref T85281.
Differential Revision: https://developer.blender.org/D10451
Previously, when the output of a Geometry Nodes modifier would
contain instances, those could not be accessed by other existing
modifiers (e.g. the Array modifier). That is because those modifiers
don't know about instances.
Upcoming commits will improve an this in two ways:
* Also realize instances before deform modifiers.
* Convert a point cloud in the geometry to mesh vertices so that
they can be accessed as well.
Note, making instances real can result in loosing some information
that we do not support in Geometry Nodes yet. That includes some
special builtin attributes like bevel weights.
Ref T85281.
Differential Revision: https://developer.blender.org/D10432
Because the the vertex group name-to-index map is stored in the object
rather than object data, the object info node has to replace the
map when it replaces the mesh component on the geometry set with mesh
data from another object.
This normally works fine as a way to use the vertex groups from the
input mesh, but when passing this mesh to the next modifier, the entire
mesh component was replaced, removing the vertex group name map.
This commit adds a function to replace only the mesh data in mesh
component, uses it in the modifier code, and updates the relevant
comments.
Note that the fact that vertex group names are stored in object data
is a legacy design decision that should be reevaluated at some point.
Differential Revision: https://developer.blender.org/D10256
This implements the design proposed in T83357.
The goal is to allow the geometry nodes modifier on mesh objects to
output instances and potentially other geometry types. Both problems
are tackled by allowing mesh objects to evaluate to a geometry set,
instead of just a single mesh id data block. The geometry set can
contain a mesh but also other data like instances and a point cloud.
I can't say that I'm sure that this commit won't introduce bugs. Mainly
the temporary object creation during rendering seems a bit brittle.
BUT, we can be reasonably sure that this commit will not introduce
regressions (at least not ones, that are hard to fix). This is because
the code has been written in a way that minimizes changes for existing
functionality.
Given that we intend to hide the point cloud object for the next release,
we won't even have to worry about temporary object creation for now.
An important part of the technical design is to make sure that
`ObjectRuntime->data_eval` contains the same data before and after this
patch. This helps to make sure, that existing code paths are impacted as
little as possible.
Instead of fully replacing `data_eval`, there is `geometry_set_eval`,
which contains all the geometry components an object evaluated to
(including the data referenced by `data_eval`).
For now, not much code has to be aware of `geometry_set_eval`. Mainly
the depsgraph object iterator and the instances system have to know
about it.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D9851
Required changes to make it compile with clang tidy:
* Use c++ includes like (e.g. climits instead limits.h).
* Insert type casts when casting from void* to something else.
* Replace NULL with nullptr.
* Insert casts from int to enum.
* Replace designed initializers (not supported in C++ yet).
* Use blender::Vector instead of BLI_array_staticdeclare (does not compile with C++).
* Replace typedef statements.
Ref T83357.
