Make it harder to retrieve a mutable attribute from const a const mesh,
and use the attribute search function to check multiple domains and
colors at once.
Clay strips was using it's own brush local matrix,
which wasn't quite compatible with texture matrices.
This could lead to brush textures not lining up with
the stroke dabs.
There was also a bug where the stroke was starting
20 pixels into the stroke, which is much higher than
necassary to derive the initial rake angle.
Notes:
* The clay strips brush now uses SCULPT_cube_tip_init
to calculate the local brush matrix.
* SCULPT_cube_tip_init now accepts custom brush location
and radius arguments.
* The mouse sample preroll used to calculate initial brush
rotation angle is now smaller than the update interval.
* Clay strips now supports tip_scale_x, which has also
been added to DNA defaults.
Split much of BKE_pbvh.h into BKE_pbvh_api.hh.
BKE_pbvh.h is included by BKE_paint.h, which in
turn is included by large amounts of code including
RNA.
This makes it extremely difficult to change
or clean up the PBVH API, since each modification
of BKE_pbvh.h can take 20-30 minutes to compile,
even on a quad-core system with an SSD. This
commit fixes that by moving most of BKE_pbvh.h
into another file and just having the core,
external-facing interfaces in BKE_pbvh.h.
Renames `OB_MODE_EDIT_GPENCIL`, `OB_MODE_PAINT_GPENCIL`, `OB_MODE_SCULPT_GPENCIL`, `OB_MODE_WEIGHT_GPENCIL`, `OB_MODE_VERTEX_GPENCIL, and the context modes` to `*_LEGACY`.
Pull Request: https://projects.blender.org/blender/blender/pulls/109648
The "Fill" message can be either a noun or a verb. This commit
disambiguates the verb usages for translation through various
translation contexts.
The more involved change is in the generation of keymaps from paint
modes. By default, the enums defining brush names are in the default
context, but this commit changes the ones including a "Fill" item to
"Brush". In order to get the same contexts in the keymap, we introduce
a specific function in `paint.cc` to return the appropriate context
depending on the tool.
Issue reported by Gabriel Gazzán (@GabrielGazzan) in #43295.
Pull Request: https://projects.blender.org/blender/blender/pulls/108561
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
When entering sculpt mode on an object without any color attributes and
starting to paint, the newly created color attribute was set active, but
not default (camera icon).
Now set it default as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/108271
Combine the newer less efficient C++ implementations and the older
less convenient C functions. The maps now contain one large array of
indices, split into groups by a separate array of offset indices.
Though performance of creating the maps is relatively unchanged, the
new implementation uses 4 bytes less per source element than the C
maps, and 20 bytes less than the newer C++ functions (which also
had more overhead with larger N-gons). The usage syntax is simpler
than the C functions as well.
The reduced memory usage is helpful for when these maps are cached
in the near future. It will also allow sharing the offsets between
maps for different domains like vertex to corner and vertex to face.
A simple `GroupedSpan` class is introduced to make accessing the
topology maps much simpler. It combines offset indices and a separate
span, splitting it into chunks in an efficient way.
Pull Request: https://projects.blender.org/blender/blender/pulls/107861
The usage of the lib pointer was cryptic to say the least, it was
essentialy used to allow or not local IDs results in the mapping
old_id_pointer -> new_id_pointer lookup result.
Now:
- Explicitely pass a boolean to allow or not local ID as result in
lower-level code.
- Pass the 'self ID' pointer instead of its library to the whole
liblinking code (that was already the case in a few places).
Note that naming of the 'self id' pointer is currently very inconsistent
throughout the readfile liblink code, this will have to be cleaned up in
a separate step later. For now, `self_id` has been chosen for new code
as it matches the terminology in lib_query code.
The later change can also allow finer handling of lookup on undo, based
on how it was re-read (or not), should the need for this arise.
Change PBVH normal calculation to also update vertices connected to
vertices with an update tag. This is necessary because vertex normals
are the mixed face normals, so changing any face's normal will change
the normals of all connected faces.
This change requires that the PBVH always have a vertex to face
topology map available. In the future this will likely be cached on
meshes though, which will reduce the delay it adds when entering sculpt
mode.
Now, first all face normals are updated, then the normals for
connected vertices are mixed from the face normals. This is a
significant simplification to the whole process, which previously
worked with atomics and normals at the triangle level. Similar changes
changes for regular non-sculpt normal calculation are being worked on
in #105920.
Pull Request: https://projects.blender.org/blender/blender/pulls/107458
For derived mesh triangulation information, currently the three face
corner indices are stored in the same struct as index of the mesh
polygon the triangle is part of. While those pieces of information are
often used together, they often aren't, and combining them prevents
the indices from being used with generic utilities. It also means that
1/3 more memory has to be written when recalculating the triangulation
after deforming the mesh, and that the entire triangle data has to be
read when only the polygon indices are needed.
This commit splits the polygon index into a separate cache on `Mesh`.
The triangulation data isn't saved to files, so this doesn't affect
.blend files at all.
In a simple test deforming a mesh with geometry nodes, the time used
to recalculate the triangulation reduced from 2.0 ms to 1.6 ms,
increasing overall FPS from 14.6 to 15.
Pull Request: https://projects.blender.org/blender/blender/pulls/106774
Add the ability to retrieve implicit sharing info directly from the
C++ attribute API, which simplifies memory usage and performance
optimizations making use of it. This commit uses the additions to
the API to avoid copies in a few places:
- The "rest_position" attribute in the mesh modifier stack
- Instance on Points node
- Instances to points node
- Mesh to points node
- Points to vertices node
Many files are affected because in order to include the new information
in the API's returned data, I had to switch a bunch of types from
`VArray` to `AttributeReader`. This generally makes sense anyway, since
it allows retrieving the domain, which wasn't possible before in some
cases. I overloaded the `*` deference operator for some syntactic sugar
to avoid the (very ugly) `.varray` that would be necessary otherwise.
Pull Request: https://projects.blender.org/blender/blender/pulls/107059
While embedded IDs are usually considered as private local data of their
owner ID, some areas of code, like the depsgraph, can consider them as
regular IDs in some aspects.
So when swapping IDs, also properly 'counter-swap' their potential
embedded IDs, such that the pointers to the embedded IDs remain as before
swapping, even though the data of the embedded IDs is swapped.
The main target of this change is memfile undo code. There, newly read
IDs are swapped with their oldder version, so that the old address
contains the new data. This allows to avoid rebuilding some of the
depsgraph. Doing the same thing for embedded IDs should reduce even
further the needs for depsgrah rebuilds on undo steps.
This commit also gives more control over the remapping of 'self' ID
pointers inside themselves.
Pull Request: https://projects.blender.org/blender/blender/pulls/107044
commit 7aa5e65dcbda862dcb17ecfc6727eb241a12c316
Merge: c08a9ec19f 7c9e493da55
Author: Joseph Eagar <joeedh@gmail.com>
Date: Sun Apr 16 15:11:53 2023 -0700
Merge branch 'main' of https://projects.blender.org/ChengduLittleA/blender into ChengduLittleA-main
commit 7c9e493da55a4adbfa2415b711e6d0daa2720ad9
Author: YimingWu <xp8110@outlook.com>
Date: Fri Mar 31 17:46:32 2023 +0800
Fix#106358: Handles null evaluated object when entering sculpting workspace.
The setup where everything in the scene is invisible/not enabled could
trigger a crash when switched to sculpting workspace, triggered when
opening the file.
This patch handles such situation.
Cleaned up sculpt code to store lists of `PBVHNodes` with
`blender::Vector` instead of simple pointer arrays. This is much
simpler and eliminates memory leaks caused by forgetting to free
the result of `BKE_pbvh_search_gather`.
Notes:
* `BKE_pbvh_search_gather` is now `blender::pbvh::search_gather`.
* `FilterCache` and `ExpandCache` have ownership over their .nodes
members; as a result they're no longer pure C structs and
are allocated with `MEM_new`/`MEM_delete`.
* The word 'totnode' no longer occurs anywhere in
`source/blender/editors/sculpt_paint`
Todo (not for this PR): create a new properly C++ task API for sculpt
(with lambdas) and use it for brushes.
Pull Request: https://projects.blender.org/blender/blender/pulls/106884
I cleaned up the cube brush tip code quite a bit; more remains
to be done. There is a new function to initialize cube
tip matrices, SCULPT_cube_tip_init. It's currently only
used by the paint brush, I'll need to do a bit of testing
before using it for clay strips and multiplane scrape.
Note: SCULPT_cube_tip_init uses the brush local matrix code
to avoid code duplication (and to take advantage of the debouncing
that is done there).
Implements #95967.
Currently the `MPoly` struct is 12 bytes, and stores the index of a
face's first corner and the number of corners/verts/edges. Polygons
and corners are always created in order by Blender, meaning each
face's corners will be after the previous face's corners. We can take
advantage of this fact and eliminate the redundancy in mesh face
storage by only storing a single integer corner offset for each face.
The size of the face is then encoded by the offset of the next face.
The size of a single integer is 4 bytes, so this reduces memory
usage by 3 times.
The same method is used for `CurvesGeometry`, so Blender already has
an abstraction to simplify using these offsets called `OffsetIndices`.
This class is used to easily retrieve a range of corner indices for
each face. This also gives the opportunity for sharing some logic with
curves.
Another benefit of the change is that the offsets and sizes stored in
`MPoly` can no longer disagree with each other. Storing faces in the
order of their corners can simplify some code too.
Face/polygon variables now use the `IndexRange` type, which comes with
quite a few utilities that can simplify code.
Some:
- The offset integer array has to be one longer than the face count to
avoid a branch for every face, which means the data is no longer part
of the mesh's `CustomData`.
- We lose the ability to "reference" an original mesh's offset array
until more reusable CoW from #104478 is committed. That will be added
in a separate commit.
- Since they aren't part of `CustomData`, poly offsets often have to be
copied manually.
- To simplify using `OffsetIndices` in many places, some functions and
structs in headers were moved to only compile in C++.
- All meshes created by Blender use the same order for faces and face
corners, but just in case, meshes with mismatched order are fixed by
versioning code.
- `MeshPolygon.totloop` is no longer editable in RNA. This API break is
necessary here unfortunately. It should be worth it in 3.6, since
that's the best way to allow loading meshes from 4.0, which is
important for an LTS version.
Pull Request: https://projects.blender.org/blender/blender/pulls/105938
Vertex paint's filter operators were not properly going through the SculptSession API.
Undo didn't work; sometimes the operators would do nothing or produce corrupted colors.
The `transform_active_color` helper function now handles all of this. It ensures a valid
SculptSession exists and executes an undo push.
Reviewed By: Hans Goudey
Pull Request: https://projects.blender.org/blender/blender/pulls/106136
These `ME_POLY_LOOP_PREV` are redundant, since they're similar to
the `poly_corner_prev` inline functions. They were also confusing,
since they took an index into the poly and returned an index into
the entire corner range. Instead structure code to use the function
version, and simplify some loops in the process.
This allows adding spans, arrays, etc. directly to SculptSession, which
simplifies accessing mesh data, especially in #105938. A few files
aren't moved to C++ yes, so I had to add three C accessor functions.
Implements #102359.
Split the `MLoop` struct into two separate integer arrays called
`corner_verts` and `corner_edges`, referring to the vertex each corner
is attached to and the next edge around the face at each corner. These
arrays can be sliced to give access to the edges or vertices in a face.
Then they are often referred to as "poly_verts" or "poly_edges".
The main benefits are halving the necessary memory bandwidth when only
one array is used and simplifications from using regular integer indices
instead of a special-purpose struct.
The commit also starts a renaming from "loop" to "corner" in mesh code.
Like the other mesh struct of array refactors, forward compatibility is
kept by writing files with the older format. This will be done until 4.0
to ease the transition process.
Looking at a small portion of the patch should give a good impression
for the rest of the changes. I tried to make the changes as small as
possible so it's easy to tell the correctness from the diff. Though I
found Blender developers have been very inventive over the last decade
when finding different ways to loop over the corners in a face.
For performance, nearly every piece of code that deals with `Mesh` is
slightly impacted. Any algorithm that is memory bottle-necked should
see an improvement. For example, here is a comparison of interpolating
a vertex float attribute to face corners (Ryzen 3700x):
**Before** (Average: 3.7 ms, Min: 3.4 ms)
```
threading::parallel_for(loops.index_range(), 4096, [&](IndexRange range) {
for (const int64_t i : range) {
dst[i] = src[loops[i].v];
}
});
```
**After** (Average: 2.9 ms, Min: 2.6 ms)
```
array_utils::gather(src, corner_verts, dst);
```
That's an improvement of 28% to the average timings, and it's also a
simplification, since an index-based routine can be used instead.
For more examples using the new arrays, see the design task.
Pull Request: https://projects.blender.org/blender/blender/pulls/104424
Change code fragments where `BKE_mesh_vert_coords_alloc` had been used
to temporarily copy vertex coordinates of a mesh (see #103789) and
providd pointers to the mesh's stored vertex positions instead.
This reduces memory usage and improves performance.
Pull Request: https://projects.blender.org/blender/blender/pulls/105756
This simplifies the usage of the API and is preparation for #104478.
The `CustomData_add_layer` and `CustomData_add_layer_named` now have corresponding
`*_with_data` functions that should be used when creating the layer from existing data.
Pull Request: https://projects.blender.org/blender/blender/pulls/105708
Refactoring mesh code, it has become clear that local cleanups and
simplifications are limited by the need to keep a C public API for
mesh functions. This change makes code more obvious and makes further
refactoring much easier.
- Add a new `BKE_mesh.hh` header for a C++ only mesh API
- Introduce a new `blender::bke::mesh` namespace, documented here:
https://wiki.blender.org/wiki/Source/Objects/Mesh#Namespaces
- Move some functions to the new namespace, cleaning up their arguments
- Move code to `Array` and `float3` where necessary to use the new API
- Define existing inline mesh data access functions to the new header
- Keep some C API functions where necessary because of RNA
- Move all C++ files to use the new header, which includes the old one
In the future it may make sense to split up `BKE_mesh.hh` more, but for
now keeping the same name as the existing header keeps things simple.
Pull Request: https://projects.blender.org/blender/blender/pulls/105416
Similar to the previous commit, this simplifies future refactoring
to change the way edges are stored, and further differentiates
single poly variables from array pointers.
With the goal of clearly differentiating between arrays and single
elements, improving consistency across Blender, and using wording
that's easier to read and say, change variable names for Mesh edges
and polygons/faces.
Common renames are the following, with some extra prefixes, etc.
- `mpoly` -> `polys`
- `mpoly`/`mp`/`p` -> `poly`
- `medge` -> `edges`
- `med`/`ed`/`e` -> `edge`
`MLoop` variables aren't affected because they will be replaced
when they're split up into to arrays in #104424.
