Commit Graph

12 Commits

Author SHA1 Message Date
Sergey Sharybin d174959759 Fix #120051: Crash when using shrinkwrap with Target Normal Project
The issue was introduced by b35831ad6c.

Since that commit `tree->boundary` will always be non-nullptr, even
when the target mesh had no boundaries. Some code was still relying
on the fact that `tree->boundary != nullptr` means the mesh has
boundary.

Update shrinkwrap code for this fact, avoiding access past array
boundaries.

Pull Request: https://projects.blender.org/blender/blender/pulls/120054
2024-03-29 11:43:15 +01:00
Hans Goudey 0b80d5e755 Cleanup: Access sharp_face attribute with attribute API 2024-03-28 14:45:56 -04:00
Hans Goudey b35831ad6c Mesh: Use shared cache for shrinkwrap boundary data
This is mainly to make the computation threadsafe, to allow computing
the cache on a const mesh, and also to decrease the cost of copying
meshes. Computing caches on const meshes generally makes it easier
to avoid copying meshes unnecessarily in other ways, which would be
useful for some pending fixes and cleanups to modifier evaluation.
2024-03-27 22:25:09 -04:00
Hans Goudey 278c5c9c7e Cleanup: Simplify shrinkwrap cache creation
- Use C++ Array type
- Move to blender::bke::shrinkwrap namespace
- Use edge_is_boundary instead of edge_mode in a few places
- Avoid writing to edge_mode unnecessarily
2024-03-27 22:25:09 -04:00
Campbell Barton 6f6a6ace39 Cleanup: redundant forward declarations of structs 2024-03-08 11:31:11 +11:00
Lukas Tönne f51e93bec7 GPv3: Shrinkwrap modifier
Port of shrinkwrap modifier from GPv2.

Adds a new API function in `BKE_shrinkwrap.hh` for the modifier.

Pull Request: https://projects.blender.org/blender/blender/pulls/119118
2024-03-06 12:05:00 +01:00
Hans Goudey 7c69c8827b Mesh: Rename MLoopTri variable names, and functions
Make the naming consistent with the recent change from "loop" to
"corner". Avoid the need for a special type for these triangles by
conveying the semantics in the naming instead.

- `looptris` -> `corner_tris`
- `lt` -> `tri` (or `corner_tri` when there is less context)
- `looptri_index` -> `tri_index` (or `corner_tri_index`)
- `lt->tri[0]` -> `tri[0]`
- `Span<MLoopTri>` -> `Span<int3>`
- `looptri_faces` -> `tri_faces` (or `corner_tri_faces`)

If we followed the naming pattern of "corner_verts" and "edge_verts"
exactly, we'd probably use "tri_corners" instead. But that sounds much
worse and less intuitive to me.

I've found that by using standard vector types for this sort of data,
the commonalities with other areas become much clearer, and code ends
up being naturally more data oriented. Besides that, the consistency
is nice, and we get to mostly remove use of `DNA_meshdata_types.h`.

Pull Request: https://projects.blender.org/blender/blender/pulls/116238
2023-12-19 14:57:49 +01:00
Hans Goudey c293c75975 Cleanup: Avoid passing context to shrinkwrap blenkernel function
Such lower level functions generally shouldn't know about Blender's
overall context. If that spreads everywhere, things get hard to reason
about.
2023-12-04 15:29:40 -05:00
Hans Goudey 695e626d3f Cleanup: Store more mesh runtime data with unique_ptr
Convert shrinkwrap data arrays to use C++ arrays and BitVector,
use references in "EditMeshData" code, and store both structs
with `std::unique_ptr` instead of a raw allocation.
2023-12-04 15:23:24 -05:00
Hans Goudey aca27e5462 Cleanup: Store BVH and shrinkwrap data with C++ types 2023-11-28 16:40:43 -05:00
Hans Goudey 9271949f7b Cleanup: Remove unnecessary keywords from newly C++ headers 2023-11-28 16:13:09 -05:00
Hans Goudey 7e3ba529ea Cleanup: Move four blenkernel headers to C++ 2023-11-28 16:05:12 -05:00