| Age | Commit message (Collapse) | Author |
|---|
|
The goal is to improve clarity and readability, without
introducing big design changes.
Follows the recent obmat to object_to_world refactor: the
similar naming is used, and it is a run-time only rename,
meaning, there is no affect on .blend files.
This patch does not touch the redundant inversions. Those
can be removed in almost (if not all) cases, but it would
be the best to do it as a separate change.
Differential Revision: https://developer.blender.org/D16367
|
|
Motivation is to disambiguate on the naming level what the matrix
actually means. It is very easy to understand the meaning backwards,
especially since in Python the name goes the opposite way (it is
called `world_matrix` in the Python API).
It is important to disambiguate the naming without making developers
to look into the comment in the header file (which is also not super
clear either). Additionally, more clear naming facilitates the unit
verification (or, in this case, space validation) when reading an
expression.
This patch calls the matrix `object_to_world` which makes it clear
from the local code what is it exactly going on. This is only done
on DNA level, and a lot of local variables still follow the old
naming.
A DNA rename is setup in a way that there is no change on the file
level, so there should be no regressions at all.
The possibility is to add `_matrix` or `_mat` suffix to the name
to make it explicit that it is a matrix. Although, not sure if it
really helps the readability, or is it something redundant.
Differential Revision: https://developer.blender.org/D16328
|
|
BKE_sculpt_mask_layers_ensure now takes a depsgraph argument and
will evaluate the depsgraph if a multires mask layer is added.
This is necassary to update the multires runtime data so that
pbvh knows it has a grids mask layer.
Also added code to update pbvh->gridkey.
|
|
|
|
Similar to the other refactors from T95965, this commit moves sculpt
face sets to use a generic integer attribute named `".sculpt_face_set"`.
This makes face sets accessible in the Python API.
The attribute is not visible in the attributes list or the spreadsheet
because it is meant for internal use, though that could be an option
in the future along with other similar attributes. Currently the change
is small, but in the future this could simplify code by allowing use
of more generic attribute APIs.
Differential Revision: https://developer.blender.org/D16045
|
|
corresponding data layers and using their values for computations.
Avoiding that should increase performance in many operations that
would otherwise have to read, write, or propagate these values.
It also means decreased memory usage-- not just for sculpt mode
but for any mesh that was in sculpt mode. Previously the mask, face set,
and hide status layers were *always* allocated by sculpt mode.
Here are a few basic tests when masking and face sets are not used:
| Test | Before | After |
| Subsurf Modifier | 148 ms | 126 ms |
| Sculpt Overlay Extraction | 24 ms every redraw | 0 ms |
| Memory usage | 252 MB | 236 MB |
I wouldn't expect any difference when they are used though.
The code changes are mostly just making sculpt features safe for when
the layers aren't stored, and some changes to the conversion to and
from the hide layers. Use of the ".hide_poly" attribute replaces testing
whether face sets are negative in many places.
Differential Revision: https://developer.blender.org/D15937
|
|
- Remove "take ownership" argument which was confusing and always true
- The argument made ownership very confusing
- Better to avoid boolean arguments that switch a function's purpose
- Remove "mask" argument which was basically wrong and not used properly
- "EVERYTHING" was used because developers are wary of removing data
- Instead use `CD_MASK_MESH` for its purpose of original mesh data
- Remove use of shallow copied temporary mesh, which is unnecessary now
- Split shape key processing into separate functions and use C++ types
- Copy fields explicitly rather than using memcpy for the whole struct
- Use higher level functions and avoid redundant code
- The whole idea is pretty simple and can be built from standard logic
- Adjust `CustomData` logic to be consistent with "assign" expectations
- Clear the layer data from the source, and moves the anonymous ID
Differential Revision: https://developer.blender.org/D15857
|
|
Use `verts` instead of `vertices` and `polys` instead of `polygons`
in the API added in 05952aa94d33eeb50. This aligns better with
existing naming where the shorter names are much more common.
|
|
For copy-on-write, we want to share attribute arrays between meshes
where possible. Mutable pointers like `Mesh.mvert` make that difficult
by making ownership vague. They also make code more complex by adding
redundancy.
The simplest solution is just removing them and retrieving layers from
`CustomData` as needed. Similar changes have already been applied to
curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of
the pointers generally makes code more obvious and more reusable.
Mesh data is now accessed with a C++ API (`Mesh::edges()` or
`Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`).
The CoW changes this commit makes possible are described in T95845
and T95842, and started in D14139 and D14140. The change also simplifies
the ongoing mesh struct-of-array refactors from T95965.
**RNA/Python Access Performance**
Theoretically, accessing mesh elements with the RNA API may become
slower, since the layer needs to be found on every random access.
However, overhead is already high enough that this doesn't make a
noticible differenc, and performance is actually improved in some
cases. Random access can be up to 10% faster, but other situations
might be a bit slower. Generally using `foreach_get/set` are the best
way to improve performance. See the differential revision for more
discussion about Python performance.
Cycles has been updated to use raw pointers and the internal Blender
mesh types, mostly because there is no sense in having this overhead
when it's already compiled with Blender. In my tests this roughly
halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million
face grid).
Differential Revision: https://developer.blender.org/D15488
|
|
SCULPT_undo_push_begin no longer takes an explicit
name. Instead it takes a wmOperator pointer and uses
op->type->name for the name. This is necassary for
the redo panel to work and should fix the entire class
of bugs related to misspelled undo push names.
Cases where the calling operator is not registered
may use SCULPT_undo_push_begin_ex if desired; it
takes a name string as before.
|
|
|
|
Mask and color brushes were using the existing PBVH vertex "update tag"
to mark their modifications. This was mostly unnecessary, and causes
unnecessary calculation of normals. It also caused errors though,
because they didn't tag the corresponding PBVH node for normal
recalculation, causing problems on the borders of nodes, since one
node might accumulate into another's vertex normals, but the other
node wouldn't also accumulate and normalize the normals.
The solution is to only use the update tag for tagging deformed
vertices that need recalculated normals. Everything else is handled at
the PBVH node level (which was already the case, but it wasn't clear).
The update tag was also used for undo to tag the nodes corresponding to
changed vertices. This was wrong though, because normals and visibility
would also be recalculated for just color or mask undo steps. Instead,
just use local arrays to map from vertices to nodes.
Differential Revision: https://developer.blender.org/D15581
|
|
This is a port of sculpt-dev's `SculptVertRef` refactor
(note that `SculptVertRef was renamed to PBVHVertRef`)
to master. `PBVHVertRef` is a structure that abstracts
the concept of a vertex in the sculpt code; it's simply
an `intptr_t` wrapped in a struct.
For `PBVH_FACES` and `PBVH_GRIDS` this struct stores a
vertex index, but for `BMesh` it stores a direct pointer
to a BMVert. The intptr_t is wrapped in a struct to prevent
the accidental usage of it as an index.
There are many reasons to do this:
* Right now `BMesh` verts are not logical sculpt verts;
to use the sculpt API they must first be converted to indices.
This requires a lot of indirect lookups into tables, leading to performance
loss. It has also led to greater code complexity and duplication.
* Having an abstract vertex type makes it feasible to have one unified
temporary attribute API for all three PBVH modes, which in turn
made it rather trivial to port sculpt brushes to DynTopo in
sculpt-dev (e.g. the layer brush, draw sharp, the smooth brushes,
the paint brushes, etc). This attribute API will be in a future patch.
* We need to do this anyway for the eventual move to C++.
Differential Revision: https://developer.blender.org/D14272
Reviewed By: Brecht Van Lommel
Ref D14272
|
|
- Avoid ambiguity which caused these values to be confused, use `mval`
for region relative mouse coordinates, otherwise `event_xy`.
- Pass region relative coordinates to sample_detail_dyntopo &
sample_detail_voxel as there is no reason to use screen-space values.
- Rename invalid use of mval for screen-space coordinates.
|
|
|
|
Added a fallback path to compute the
cursor radius for when the stroke
starts over a blank area of space
(in which case SCULPT_cursor_geometry_update
fails).
|
|
This is mostly a cleanup to avoid hardcoding the eager calculation of
normals it isn't necessary, by reducing calls to `BKE_mesh_calc_normals`
and by removing calls to `BKE_mesh_normals_tag_dirty` when the mesh
is newly created and already has dirty normals anyway. This reduces
boilerplate code and makes the "dirty by default" state more clear.
Any regressions from this commit should be easy to fix, though the
lazy calculation is solid enough that none are expected.
|
|
color attribute system.
This commit removes sculpt colors from experimental
status and unifies it with vertex colors. It
introduces the concept of "color attributes", which
are any attributes that represents colors. Color
attributes can be represented with byte or floating-point
numbers and can be stored in either vertices or
face corners.
Color attributes share a common namespace
(so you can no longer have a floating-point
sculpt color attribute and a byte vertex color
attribute with the same name).
Note: this commit does not include vertex paint mode,
which is a separate patch, see:
https://developer.blender.org/D14179
Differential Revision: https://developer.blender.org/D12587
Ref D12587
|
|
|
|
Currently there is a "calc_face_normal" argument to mesh to bmesh
conversion, but vertex normals had always implicitly inherited whatever
dirty state the mesh input's vertex normals were in. Probably they were
most often assumed to not be dirty, but this was never really correct in
the general case.
Ever since the refactor to move vertex normals out of mesh vertices,
cfa53e0fbeed7178c7, the copying logic has been explicit: copy the
normals when they are not dirty. But it turns out that more control is
needed, and sometimes normals should be calculated for the resulting
BMesh.
This commit adds an option to the conversion to calculate vertex
normals, true by default. In almost all places except the decimate
and edge split modifiers, I just copied the value of the
"calc_face_normals" argument.
Differential Revision: https://developer.blender.org/D14406
|
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
This is part of the project of converting `MVert` into `float3`.
(more details in T93602), The pbvh update flag is removed and
replaced with a bitmap stored in the PBVH structure. This
patch is similar to D13878. This is mainly setup for an eventual
performance improvement by removing the extra data from
mesh vertices, but if it's consistent with testing in the other patch
doing the same thing for another "temp tag", then it may actually
increase the speed of sculpt code slightly, since less memory needs
to be loaded when checking/changing the flags.
Differential Revision: https://developer.blender.org/D14000
|
|
- Bend (Transform).
- Extrude to Cursor.
- Lasso Select (related operators such as node-cut links, mask.. etc).
- Rip Mesh / UV's.
- Vertex/Edge Slide.
|
|
|
|
|
|
2 sided faces aren't supported and will cause problems in many areas
of Blender's code.
Removing (implied) support for faces with fewer than 3 sides
means the total number of triangles is known ahead of time.
This simplifies adding support for multi-threading and partial updates
to an existing tessellation - as the face and loop indices can be used
to access the range of triangles associated with a face.
Also correct outdated comments.
|
|
Add missing operator poll, depend on the 3D view for all
sculpt paint/mask operators.
|
|
Reviewed By: JacquesLucke
Differential Revision: https://developer.blender.org/D10707
|
|
The commit rB6f63417b500d that made exact boolean work on meshes
with holes (like Suzanne) unfortunately dramatically slowed things
down on other non-manifold meshes that don't have holes and didn't
need the per-triangle insideness test.
This adds a hole_tolerant parameter, false by default, that the user
can enable to get good results on non-manifold meshes with holes.
Using false for this parameter speeds up the time from 90 seconds
to 10 seconds on an example with 1.2M triangles.
|
|
|
|
This fixes two issues that were preveting normal orientation for working:
- The translation of component of the object matrix should not be
considered when converting a normal to world space.
- Whe using cursor for depth, the depth for the shape should be taken
directly from the cursor (which is already unprojected and updated)
instead of from the brush, which may have not been updated.
Reviewed By: dbystedt, JacquesLucke
Differential Revision: https://developer.blender.org/D10231
|
|
A missing flush of the deformed PBVH coordinates to the shape key.
Reviewed By: JacquesLucke
Maniphest Tasks: T84370
Differential Revision: https://developer.blender.org/D10174
|
|
The boolean solver crashes when there is no geometry in the mesh. Also,
using the trimming tools without a valid intersection in the PBVH will
make the orientation and position functionality of the trimming shape
not work, so this is the safer solution.
Reviewed By: mont29
Maniphest Tasks: T83504
Differential Revision: https://developer.blender.org/D9777
|
|
|
|
|
|
Issue exposed by rB4c7b1766a7f1.
Main idea is that non-memfile first undo step should check into previous
memfile and tag the ID it is editing as `future_changed`.
That way, when we go back and undo to the memfile, said IDs are properly
detected as changed and re-read from the memfile.
Otherwise, undo system sees them as unchanged, and just re-use the
current data instead.
Note that currently only Sculpt mode seems affected (probably because it
is storing the mode switch itself as a Sculpt undo step instead of a
memfile one), but similar action might be needed in some other cases
too.
Maniphest Tasks: T82388
Differential Revision: https://developer.blender.org/D9510
|
|
|
|
Reviewers: pablodp606
Differential Revision: https://developer.blender.org/D9472
|
|
The code was trying to ignore hidden geometry when doing boolean,
which is correct when used as a tool, but not when a modifier.
Added a "keep_hidden" argument to bmesh_boolean to distinguish the
two cases.
Also fixed a bug when the tool is used with hidden geometry that
is attached to unhidden geometry that is deleted by the operation.
|
|
The code was trying to ignore hidden geometry when doing boolean,
which is correct when used as a tool, but not when a modifier.
Added a "keep_hidden" argument to bmesh_boolean to distinguish the
two cases.
Also fixed a bug when the tool is used with hidden geometry that
is attached to unhidden geometry that is deleted by the operation.
|
|
|
|
BKE_mesh_free() seems to not free the meshes correctly, so using BKE_id_free() instead.
The looptri array was also not freed.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D9426
|
|
|
|
This enables self intersections in the sculpt trimming tools boolean operations.
This should fix wrong booleans results after using the operator to add new disconnected
geometry with the join mode.
Reviewed By: sergey
Maniphest Tasks: T81799
Differential Revision: https://developer.blender.org/D9423
|
|
|
|
This adds an option to orientate the trimming shape using the surface
normal instead of the view when lasso trim is used.
Reviewed By: dbystedt, sergey
Differential Revision: https://developer.blender.org/D9231
|
|
This adds a tool property for sculpt line gesture tools (line and
project) to limits its effect to the segment of the gesture instead of
using the infinite line to bisect the mesh in two parts.
To achieve that, the line gesture now has two extra side planes that can
be enabled/disabled for getting the nodes from the PBVH and to test the
vertices.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D9307
|
|
shapekeys/modifiers
This was failing for all mask filters (sharpen, grow, invert, clear,
shrink, contrast, smooth) and mask gestures (box, lasso).
Also have to recalc shading, use SCULPT_tag_update_overlays for this.
ref D8956
Maniphest Tasks: T81929
Differential Revision: https://developer.blender.org/D9302
|
|
Line gesture use always the right side of the line as active (the area
of the mesh that is going to be modified) by default.
This adds the ability to change the active side when the line gesture is
active by pressing the F key.
This allows more freedom to position the line after starting the
gestures, as it won't be required to cancel the operation or undo if the
line was used in the wrong direction.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D9301
|
|
|
