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
Similar to 1a6d0ec71c which changed the mesh boolean node (and
also caused this bug), this commit changes the material mapping for the
exact mode of the boolean modifier. Now the result should contain any
material on the faces of the input objects (including materials linked
to objects and meshes). The improvement is possible because materials
can be changed during evaluation (as of 1a81d268a1).
Differential Revision: https://developer.blender.org/D15365
Curves that are attached to a surface can now follow the surface when
it is modified using shape keys or modifiers (but not when the original
surface is deformed in edit or sculpt mode).
The surface is allowed to be changed in any way that keeps uv maps
intact. So deformation is allowed, but also some topology changes like
subdivision.
The following features are added:
* A new `Deform Curves on Surface` node, which deforms curves with
attachment information based on the surface object and uv map set
in the properties panel.
* A new `Add Rest Position` checkbox in the shape keys panel. When checked,
a new `rest_position` vector attribute is added to the mesh before shape
keys and modifiers are applied. This is necessary to support proper
deformation of the curves, but can also be used for other purposes.
* The `Add > Curve > Empty Hair` operator now sets up a simple geometry
nodes setup that deforms the hair. It also makes sure that the rest
position attribute is added to the surface.
* A new `Object (Attach Curves to Surface)` operator in the `Set Parent To`
(ctrl+P) menu, which attaches existing curves to the surface and sets the
surface object as parent.
Limitations:
* Sculpting the procedurally deformed curves will be implemented separately.
* The `Deform Curves on Surface` node is not generic and can only be used
for one specific purpose currently. We plan to generalize this more in the
future by adding support by exposing more inputs and/or by turning it into
a node group.
Differential Revision: https://developer.blender.org/D14864
It's helpful to make the separation of legacy data formats explicit,
because it declutters actively changed code and makes it clear which
areas do not follow Blender's current design. In this case I separated
the `MFace`/"tessface" conversion code into a separate blenkernel
.cc file and header. This also makes refactoring to remove these
functions simpler because they're easier to find.
In the future, conversions to the `MLoopUV` type and `MVert`
can be implemented here for the same reasons (see T95965).
Differential Revision: https://developer.blender.org/D15396
In "size" voxel resolution mode, calculating the bounds of the mesh to
volume node's input mesh isn't necessary. For high poly this can take
a few milliseconds, so this commit skips the calculation unless we need
it for the "Amount" mode.
Differential Revision: https://developer.blender.org/D15324
This adds a Mesh To Volume Node T86838 based on the existing modifier.
The mesh to volume conversion is implemented in the geometry module,
and shared between the node and the modifier.
Currently the node outputs a grid with the name "density". This may
change in the future depending on the decisions made in T91668.
The original patch was by Kris (@Metricity), further implementation
by Geramy Loveless (@GeramyLoveless), then finished by Erik Abrahamsson
(@erik85).
Differential Revision: https://developer.blender.org/D10895
We store various lazily calculated caches on meshes, some of which
depend on the vertex positions staying the same. The current API to
invalidate these caches is a bit confusing. With an explicit set of
functions modeled after the functions in `BKE_node_tree_update.h`,
it becomes clear which function to call. This may become more
important if more lazy caches are added in the future.
Differential Revision: https://developer.blender.org/D14760
This patch adds a 'Intersecting Edges' output with a boolean selection
that only gives you the new edges on intersections.
Will work on a couple of examples next, this should make some
interesting effects possible (including getting us closer to the "bevel-
after-boolean-usecase")
To achieve this, a Vector is passed to `direct_mesh_boolean` when the
iMesh is still available (and intersecting edges appended), then from
those edge indices a selection will be stored as attribute.
Differential Revision: https://developer.blender.org/D15151
Instancing with geometry nodes uses just the evaluated Mesh, and ignores the
Object that it came from. That meant that it would try to look up the subsurf
modifier on the instancer object which does not have the subsurf modifier.
Instead of storing a session UUID and looking up the modifier data, store a
point to the subsurf modifier runtime data. Unlike the modifier data, this
runtime data is preserved across depsgraph CoW. It must be for the subdiv
descriptor contained in it to stay valid along with the draw cache.
As a bonus, this moves various Mesh_Runtime variables into the subsurf runtime
data, reducing memory usage for meshes not using subdivision surfaces.
Also fixes T98693, issues with subdivision level >= 8 due to integer overflow.
Differential Revision: https://developer.blender.org/D15184
Code handling repetitive boolean operations when using several objects
from a Collection would not handle result mesh properly, re-creating for
each object without properly freeing it.
Further more, existing code was effectively converting the BMesh to mesh
twice, including a modification of the initial (input) mesh, which
modifiers should never do!
Removed the extra useless conversion, which also gives a small
improvement in performances:
With as simple of a scene as four objects (three operands in a
collection, and the modified one) totalling 20k vertices/faces, this
commit:
* Avoids 2MB memory leak per evaluation (!).
* Speeds up boolean evaluation by 5-10%.
Found while investigating some production files of the Project Heist
here at the Blender Studio.
This is an extension of 4669178fc3, applying the same changes to
attributes chosen in the field inputs of the geometry nodes modifier.
If a UI/internal attribute is used, the attribute name button will
have a red alert. Adding a disabled hint is currently a bit more complex.
Also hide UI attributes in attribute search for the named attribute node.
Part of D14934
`bNodeTree` has a lot of run-time embedded in it currently. Having a separately
allocated run-time struct has some benefits:
* Run-time data is not stored in files.
* Makes it easy to use c++ types as run-time data.
* More clear distinction between what data only exists at run-time and which doesn't.
This commit doesn't move all run-time data to the new struct yet, only the data where
I know for sure how it is used. The remaining data can be moved separately.
Differential Revision: https://developer.blender.org/D15033
The problem is that depsgraph evaluation happens before the OpenGL context
is initialized, and so modifier evaluation happens without GPU subdivision.
Later the BKE_subsurf_modifier_can_do_gpu_subdiv test in the draw code gives
a different result.
This just checks if the mesh has information for GPU subdivision in the draw
code, and if so uses it. This is only set if the test for supported GPU
subdivision passes in the modifier evaluation.
Additionally it may be good to perform OpenGL context initialization earlier
so background render can take advantage of GPU subdivision, but this is more
complicated.
Differential Revision: https://developer.blender.org/D14969
This removes the manual construction of a box mesh in the mesh sequence
cache modifier when the Alembic procedural is enabled. It also removes
the use of `BKE_object_boundbox_get` which doesn't make sense on a
non-evaluated object.
Differential Revision: https://developer.blender.org/D14958
Skip writing binding data and similar for override modifiers already
present in reference linked data, as this can use a lot of space, and
is fully useless data typically since we already skip writing Mesh
geometry data itself.
Ref. T97967.
Skip writing binding data and similar for override modifiers already
present in reference linked data, as this can use a lot of space, and
is fully useless data typically since we already skip writing Mesh
geometry data itself.
Ref. T97967.
Skip writing binding data and similar for override modifiers already
present in reference linked data, as this can use a lot of space, and
is fully useless data typically since we already skip writing Mesh
geometry data itself.
Ref. T97967.
Skip writing binding data and similar for override modifiers already
present in reference linked data, as this can use a lot of space, and
is fully useless data typically since we already skip writing Mesh
geometry data itself.
Ref. T97967.
This changes is needed to give more control to modifiers' writing
callback when defined. It will allow to implement better culling of
needless data when writing e.g. modifiers from library overrides.
Ref. T97967.
Reviewed By: brecht, JacquesLucke
Differential Revision: https://developer.blender.org/D14939
Knowing when layers are retrieved for write access will be essential
when adding proper copy-on-write support. This commit makes that
clearer by adding `const` where the retrieved data is not modified.
Ref T95842
This abuse of one one size value to handle another allocated array of a
different size is bad in itself, but at least now read/write code of
this modifier should not risk invalid memory access anymore.
NOTE: invalid memory access would in practice only happen in case endian
switch would be performed at read time I think (those switches only check
for given length being non-zero, not for a NULL data pointer...).
If merging is enabled, the mesh might be recreated before
the dirty flag can be cleared, which means the normals aren't
valid anymore. To fix this, clearing the dirty flag should happen
before the merging. This is an existing bug, just exposed by
more recent explicit dirty normal tagging.
Geometry Nodes (new) icon. So far we were using the generic node-tree
icon for geometry nodes, not anymore.
The new icon is composed of 4 spheres that is a reference to the
original pebbles demo. Scattering points was also the turning point for
the project (which originally was focusing on dynamic effects), and to
this day is one of the first steps for everything procedural such as
hair.
Note that the modifier icon is still showing as white in the outliner.
The alternative is to be blue everywhere.
Patch review and feedback by Hans Goudey.
Icon creation in collaboration with Pablo Vazquez.
The modifier is supposed to create a Curves data block soon, which
helps with the transition to the new Curves object in drawing code.
Utilities for the new Curves object are mostly in C++.
A studio request actually.
The goal is to cover rather typical situation: when the mesh was
bound to target when the target was on subdivision level 0 but
uses a higher subdivision level for rendering. Example of such
setup is a facial hair bound to the face.
The idea of this change is to use first N vertices from the target
where N is the number of vertices on target during binding process.
While this sounds a bit arbitrary it covers typical modifier setup
used for rigging. Arguably, it is not more arbitrary than using a
number of polygons (which is how the modifier was checking for
changes on target before this change).
Quite straightforward change. A bit tricky part was to not break
the behavior since before this change we did not track number of
vertices sued when binding. The naming I'm also not super happy
with and just followed the existing one. Ideally the variables in
DNA will be prefixed with `target_` but doing it for an existing
field would mean compatibility change, and only using prefix for
the new field will introduce weird semantic where the polygons
count will be even more easily confused with a count on the
deforming mesh.
Differential Revision: https://developer.blender.org/D14830
Make it explicit that counter is about target mesh.
Use DNA rename for it so that the files stay compatible.
Also renamed some purely runtime fields to replace `t`
prefix with `target` as the short `t` is super easy
to miss.
Differential Revision: https://developer.blender.org/D14835
