Design task: #93551
This PR replaces the auto smooth option with a geometry nodes modifier
that sets the sharp edge attribute. This solves a fair number of long-
standing problems related to auto smooth, simplifies the process of
normal computation, and allows Blender to automatically choose between
face, vertex, and face corner normals based on the sharp edge and face
attributes.
Versioning adds a geometry node group to objects with meshes that had
auto-smooth enabled. The modifier can be applied, which also improves
performance.
Auto smooth is now unnecessary to get a combination of sharp and smooth
edges. In general workflows are changed a bit. Separate procedural and
destructive workflows are available. Custom normals can be used
immediately without turning on the removed auto smooth option.
**Procedural**
The node group asset "Smooth by Angle" is the main way to set sharp
normals based on the edge angle. It can be accessed directly in the add
modifier menu. Of course the modifier can be reordered, muted, or
applied like any other, or changed internally like any geometry nodes
modifier.
**Destructive**
Often the sharp edges don't need to be dynamic. This can give better
performance since edge angles don't need to be recalculated. In edit
mode the two operators "Select Sharp Edges" and "Mark Sharp" can be
used. In other modes, the "Shade Smooth by Angle" controls the edge
sharpness directly.
### Breaking API Changes
- `use_auto_smooth` is removed. Face corner normals are now used
automatically if there are mixed smooth vs. not smooth tags. Meshes
now always use custom normals if they exist.
- In Cycles, the lack of the separate auto smooth state makes normals look
triangulated when all faces are shaded smooth.
- `auto_smooth_angle` is removed. Replaced by a modifier (or operator)
controlling the sharp edge attribute. This means the mesh itself
(without an object) doesn't know anything about automatically smoothing
by angle anymore.
- `create_normals_split`, `calc_normals_split`, and `free_normals_split`
are removed, and are replaced by the simpler `Mesh.corner_normals`
collection property. Since it gives access to the normals cache, it
is automatically updated when relevant data changes.
Addons are updated here: https://projects.blender.org/blender/blender-addons/pulls/104609
### Tests
- `geo_node_curves_test_deform_curves_on_surface` has slightly different
results because face corner normals are used instead of interpolated
vertex normals.
- `bf_wavefront_obj_tests` has different export results for one file
which mixed sharp and smooth faces without turning on auto smooth.
- `cycles_mesh_cpu` has one object which is completely flat shaded.
Previously every edge was split before rendering, now it looks triangulated.
Pull Request: https://projects.blender.org/blender/blender/pulls/108014
Note 0a0a29887d / 4c99043a85 were supposed to fix this.
This was mostly working, but verts could still obtain wrong weights
(most notably "outside" the gradient range).
Code from above commits would correctly skip hidden verts in
`gradientVertUpdate__mapFunc`.
However, `gradientVertInit__mapFunc` (called prior) already does
`gradientVert_update` once [not entirely sure why it does this, but
wouldnt want to remove the call there due to unforseen behavioral
changes] and we dont early out there.
So now move the check for hidden verts from
`gradientVertUpdate__mapFunc` to `gradientVertInit__mapFunc` and early
out (also saves us from doing other unneccessary stuff there).
Pull Request: https://projects.blender.org/blender/blender/pulls/113825
Currently object bounds (`object.runtime.bb`) are lazily initialized
when accessed. This access happens from arbitrary threads, and
is unprotected by a mutex. This can cause access to stale data at
best, and crashes at worst. Eager calculation is meant to keep this
working, but it's fragile.
Since e8f4010611, geometry bounds are cached in the geometry
itself, which makes this object-level cache redundant. So, it's clearer
to build the `BoundBox` from those cached bounds and return it by
value, without interacting with the object's cached bounding box.
The code change is is mostly a move from `const BoundBox *` to
`std::optional<BoundBox>`. This is only one step of a larger change
described in #96968. Followup steps would include switching to
a simpler and smaller `Bounds` type, removing redundant object-
level access, and eventually removing `object.runtime.bb`.
Access of bounds from the object for mesh, curves, and point cloud
objects should now be thread-safe. Other object types still lazily
initialize the object `BoundBox` cache since they don't have
a data-level cache.
Pull Request: https://projects.blender.org/blender/blender/pulls/113465
Mainly to simplify code and also add some add type safety, replace
`GSet` with `blender::Set` for the storage of BMesh triangles and
vertices on each PBVH node. Some initial tests point to better
performance too, but the numbers are hard to verify so far.
Because of the larger `PBVHNode`, memory usage slightly increases
(observed a 2% increase with a 1M face grid) for regular Mesh sculpting,
but it seems `Set` is more memory efficient than `GSet`, because I also
observed a 10% decrease in memory usage for dynamic topology.
In the future nodes can be split in a more data-oriented fashion to
reduce memory usage overall.
This also makes it simpler to switch to another type in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/113907
Previously, Grease Pencil used a radius convention where
1 "px" = 0.001 units. This "px" was the brush size which would be
stored in the stroke thickness and then scaled by the point pressure
factor. Finally, the render engine would divide this thickness value by
2000 (we're going from a thickness to a radius, hence the factor of
two) to convert back into blender units.
Store the radius now directly in blender units. This makes it
consistent with how hair curves handle the radius.
* Removes the scaling in the render engine.
* Makes sure the grease pencil primitives use the correct radii
* Changes the drawing tool to work with screen space radius
* Draws the drawing tool cursor in screen space
* Makes sure the scaling is done when converting from legacy
grease pencil objects
* Makes sure the scaling is done when loading previous files
Consequences for the draw tool:
* Since the tool has a radius input in pixels, it now works in screen space. This is a pretty big change to how it works by default before, so a new option will have to be added that allows the brush to be in "Scene" space. This is similar to how it works in sculpt mode. But this is a bigger change, so I would like to split that into a separate PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/113770
Significantly reduce the amount of manual memory management by
replacing owning pointers with `blender::Array`. This also simplifies
counting the size of the undo steps and iterating over the array values
in some cases.
No functional changes
The following functions have been moved
`autokeyframe_cfra_can_key`
`autokeyframe_object`
`ED_autokeyframe_object`
`ED_autokeyframe_pchan`
`ED_autokeyframe_property`
they are all in a new file
keyframing_auto.cc
while the declarations are in
ANIM_keyframing.cc
The autokeyframe makros also have been moved
Pull Request: https://projects.blender.org/blender/blender/pulls/113607
This adds `GreasePencilEditHints` and correctly implements
`crazyspace::get_evaluated_grease_pencil_drawing_deformation`
to support querying the deformation of points after evaluation.
This is needed for users to properly select points in edit mode while
seeing the effects of the modifiers.
Pull Request: https://projects.blender.org/blender/blender/pulls/113586
This is already separated per PBVH type, we can make use of that
to simplify the loops for the types with the aim of sharing code in
a simpler and more performance-friendly way. Ideally this could
be written as `array_utils::scatter`, but we don't have that utility
function now, so just write the raw loop for now.
The crash was happening because the storage buffer for active smoothing
was not resized correctly as the active smoothing window changed.
This fix makes sure the storage buffer is resized correctly.
This was because the size and bounds of points were not properly
checked in some places.
Additionally, the smoothing algorithm should only be run if the
smoothing window is larg enough.
Code to insert new keyframe when drawing is included in
7e87435cf4 . But current condition fails
to add new frame. In `frame_key_at()`, last drawing or the next drawing is
returned (instead of -1). Hence, no new drawing/frame was added in draw-invoke
function.
So add keyframe if no keyframe exists already at `current_number`
Pull Request: https://projects.blender.org/blender/blender/pulls/113408
Two aspects to this change:
- Do not clear face sets when enabling dynamic topology
- Draw face sets in viewport when dynamic topology is enabled
Newly added faces in the dynamic topology will have face
sets properly assigned. It is only edge collapse which can
potentially lead to undesired results w.r.t face set boundaries.
That will be worked on further as follow up development.
Pull Request: https://projects.blender.org/blender/blender/pulls/113348
This PR implements an initial drawing tool that can already be used for testing.
While this is not fully feature complete (compared to the current grease pencil draw tool) the following is already implemented:
* Pressure support for radius and opacity.
* Material color and vertex color support.
* New active smoothing algorithm based on curve fitting.
* Simplify algorithm as a post-process step.
Some deliberate limitations include:
* The drawing plane is always the front plane. Drawing on surfaces is also not supported.
*
The current approach has not been optimized for performance yet. The goal was to have a straightforward implementation
first and then focus on performance later.
There are numerous parameters in the code that are hard-coded for now. These should be exposed at some point, potentially as user settings.
Pull Request: https://projects.blender.org/blender/blender/pulls/110093
This is a solution to avoid redrawing the depth buffer for each Zoom
with `Auto Depth`.
The solution is to move the `ED_view3d_depth_override` function out of
`ED_view3d_autodist`.
`ED_view3d_depth_override` is now only called for navigation operations
if it does not meet the following condition:
```
bool has_depth_buffer = !(v3d->flag2 & V3D_HIDE_OVERLAYS) ||
ELEM(v3d->shading.type, OB_SOLID, OB_MATERIAL) ||
XRAY_FLAG_ENABLED(v3d) ||
v3d->shading.type == OB_RENDER &&
(strcmp(DEG_get_evaluated_scene(depsgraph)->r.engine,
RE_engine_id_BLENDER_EEVEE) == 0 ||
strcmp(DEG_get_evaluated_scene(depsgraph)->r.engine,
RE_engine_id_BLENDER_WORKBENCH) == 0);
```
After 97f2b01ea9, the iterator's mask data is just read only,
so there's no point in storing it as a pointer. This simplifies the code
using the mask data, since the default only needs to be handled once.
The expand operator reused `SCULPT_UPDATE_MASK` even when it
changed face sets, not the mask. That triggered incorrect behavior in
`node_update_mask_redraw` when there was no mask layer, which caused
nodes to be incorrectly marked as fully masked (and therefore optimized
out of later operations).
The expand operator reused `SCULPT_UPDATE_MASK` even when it
changed face sets, not the mask. That triggered incorrect behavior in
`node_update_mask_redraw` when there was no mask layer, which caused
nodes to be incorrectly marked as fully masked (and therefore optimized
out of later operations).
Currently if there is no selection mode enabled the operator is disabled and greyed
out in the menu. The shortcut doesn't do anything, which can be unexpected and jarring.
With this PR the operator will work when no selection mode is enabled and in that case
fill the entire mesh using the Weight from the active tool.
This is then consistent with vertex paint mode and the "Set Vertex Color" operator.
So now remove the overly-strict `mask_paint_poll` poll (and replace with
more appropriate `weight_paint_mode_poll`).
NOTE: `mask_paint_poll` is now unused, could be removed
Pull Request: https://projects.blender.org/blender/blender/pulls/112413
Currently the iteration over a PBVH node's vertices retrieves mutable
access to the mask custom data layer. This isn't threadsafe, but it is
done in the multithreaded loops over all nodes.
In general, we need to be more careful and conservative about storage
of non-const pointers to mesh data. Ideally we would only have one
mutable reference to a resource at a time. And we should avoid doing
work like looking up custom data layers more than we need to.
To that end, make the pointer to the custom data layer used everywhere
const, and retrieve mutable access before parallel node iteration with
a specific function, and write to the mask data with that in mind.
This pushes us in the direction of sharing less code per PBVH type.
In my opinion that's a good thing, because we can actually optimize for
each type. For example, `write_mask_data` gives a picture of
how each of these hot loops could become much simpler.
Pull Request: https://projects.blender.org/blender/blender/pulls/112690
The "mask expand" operator from 0083c96125 is not exposed in
the UI and is redundant with the addition of the more general "expand"
operator from 82e7032477. The latter commit even mentioned
that the first mask expand operator was made obsolete.
Pull Request: https://projects.blender.org/blender/blender/pulls/112726
- Add IDP_EnsureProperties,
- Remove create_if_needed argument from IDP_GetProperties.
Split access & creation so intention reads more clearly without
looking up function arguments.
There are a couple of functions that create rna pointers. For example
`RNA_main_pointer_create` and `RNA_pointer_create`. Currently, those
take an output parameter `r_ptr` as last argument. This patch changes
it so that the functions actually return a` PointerRNA` instead of using
the output parameters.
This has a few benefits:
* Output parameters should only be used when there is an actual benefit.
Otherwise, one should default to returning the value.
* It's simpler to use the API in the large majority of cases (note that this
patch reduces the number of lines of code).
* It allows the `PointerRNA` to be const on the call-site, if that is desired.
No performance regression has been measured in production files.
If one of these functions happened to be called in a hot loop where
there is a regression, the solution should be to use an inline function
there which allows the compiler to optimize it even better.
Pull Request: https://projects.blender.org/blender/blender/pulls/111976
The hash tables and vector blenlib headers were pulling many more
headers than they actually need, including the C base math header,
our C string API header, and the StringRef header. All of this
potentially slows down compilation and polutes autocomplete
with unrelated information.
Also remove the `ListBase` constructor for `Vector`. It wasn't used
much, and making it easy to use `ListBase` isn't worth it for the
same reasons mentioned above.
It turns out a lot of files depended on indirect includes of
`BLI_string.h` and `BLI_listbase.h`, so those are fixed here.
Pull Request: https://projects.blender.org/blender/blender/pulls/111801
Add three cached topology maps to `Mesh`, to avoid computations when
mesh data isn't changed. Choosing the right maps to cache is a bit
arbitrary, but generally we have to start somewhere. The limiting
factor is memory usage (all the new caches combined have a
comparable footprint to a UV map).
For now, the caches added are:
- Vertex to face corner
- Vertex to face
- Face corner to face
These caches are used in quite a few places already;
- Face corner normal calculation
- UV value merging
- Setting sharp edges from face angles
- Data transfer modifier
- Voxel remesh attribute remapping
- Sculpt mode painting
- Sculpt mode normal calculation
- Vertex paint mode
- Split edges geometry node
- Mesh topology geometry nodes
Caching topology maps means they don't have to be rebuilt every time
they're used. Meshes copied but without topology changes can share
the cache, further reducing re-computations. For example, FPS with a
large mesh using the "Corners of Vertex" node went from 1.8 to 2.3.
Entering sculpt mode is slightly faster too.
There is some obvious work for future commits:
- Use caches in attribute domain interpolation
- More multithreading of second phase of map building
- Update/build caches eagerly in some geometry nodes
Pull Request: https://projects.blender.org/blender/blender/pulls/107816
A small new feature that clears the mask completely on the current mesh island.
Closes#104022
When hovering outside the object the Expand operator is running on, it will get floodfilled with the mask/face set.
Previously, when the Invert option was used, it wouldn't also clear the mask/face set when hovering outside the object.
Pull Request: https://projects.blender.org/blender/blender/pulls/111665
Since the normals are stored in a shared cache, tagging them dirty
recreated the cache from scratch when it was shared. Instead,
add a function that updates the cache in the same call as tagging
it dirty. This keeps the old state of the cache around even if it was
shared, and reflects the way that it's really the PBVH and sculpt
mode managing the dirty status of normals while sculpt mode
is active.
One consequence is that the BVH cache and the triangulation
cache need to be tagged dirty manually. I'd like to avoid abstracting
this more than necessary, because I'm hoping in the long term
different caching abstractions like a more global cache that takes
implicit sharing versions into account will make this complexity
unnecessary.
Fixes#111628, #111563
Pull Request: https://projects.blender.org/blender/blender/pulls/111641
The `EdgeHash` and `EdgeSet` data structures are designed specifically
as a hash of an order agnostic pair of integers. This specialization can
be achieved much more easily with the templated C++ data structures,
which gives improved performance, readability, and type safety.
This PR removes the older data structures and replaces their use with
`Map`, `Set`, or `VectorSet` depending on the situation. The changes
are mostly straightforward, but there are a few places where the old
API made the goals of the code confusing.
The last time these removed data structures were significantly changed,
they were already moving closer to the implementation of the newer
C++ data structures (aa63a87d37).
Pull Request: https://projects.blender.org/blender/blender/pulls/111391
This affected sculpt, vertex- and weightpaint.
So attempting to (temporarily) switching to the smooth/blur tools from
another tool using the "Shift" shortcut can fail if the corresponding
smooth/blur brush is not found/missing [which was the case in the report
because the brush was deleted].
In this case, brushes dont really get switched, but blender would still
try to cache the size (because the smooth/blur brush temporarily uses
the same size as the previous brush) of the smooth brush in
`StrokeCache` (see `smooth_brush_toggle_on`). Then in
`smooth_brush_toggle_off` it was assumed brushes were actually switched
and the (non-existing) size of the (missing) smooth brush was applied to
the **actual** brush.
Now restructure code a bit so in the case of a missing brush we can
early out (without affecting the **actual** brush then).
Pull Request: https://projects.blender.org/blender/blender/pulls/111516
Remove the global `SculptThreadedTaskData` struct which contained
the arguments to ALL multi-threaded sculpt functions. Use the C++
threading API instead of the old task API, moving the arguments
previously stored in the shared struct to actual function arguments.
Pull Request: https://projects.blender.org/blender/blender/pulls/111525
This was noted in code comments and checked in Python documentation
generation but not at build time.
Since these enums are identifiers that end up included in various places
enforce the `rna_enum_*_items` convention which was noted as
the convention but not followed strictly.
Partially reverts [0], avoids having to deal with multiple prefix types.
[0]: 3ea7117ed1
Keeping a mutable reference to vertex normals for the entire lifetime
of the PBVH structure makes caching the normals and sharing the cache
harder than it should be. Generally code is safer when we reduce the
number of mutable references to data.
Currently the normals are modified in two places. First is the sculpt
mesh normal recalculation. There we can just retrieve the normals from
the mesh each time. Second is the restore from an undo step. That is
unnecessary because the normals are marked for recalculation anyway.
It doesn't even make much sense to store the normals in an undo step
when we can easily recalculate them based on new positions.
This change helps with #110479. These were also the last place that
kept a mutable reference to normals. I tested undo and redo after
sculpting, and it works well for each PBVH type.
Pull Request: https://projects.blender.org/blender/blender/pulls/111470
Though this means a few loops are duplicated, overall the code is
easier to reason about because the cases are separated more. This
makes potential changes to the way normals are stored clearer
(related to !110479), and makes potential optimizations easier too.
The operator handled faces visibility change correctly but not
multires. Use the existing PBVH API function for that, also remove
a redundant call to the function that fetched the attribute pointers
again after the change.
This patch refactors most of the code of the hard eraser, both for readability purpose, and to prepare the integration of the soft mode of the eraser.
The refactoring includes :
- the use of specific structures and enum types `SegmentCircleIntersection`, `PointCircleSide`, and `PointTransferData` to handle the data more easily,
- improve readability of the intersections functions (better naming, and more accurate and generic comments),
- definition of a more generic `compute_topology_change` function that handles point insertion, removal, and curve splitting for curves geometry.
Pull Request: https://projects.blender.org/blender/blender/pulls/111390
Caused by 351034891e
This change is a partial revert of the change.
The SCULPT_cube_tip_init() does not deal with the symmetry passes.
Additionally, the commit changed the way how the Z component of
the matrix was constructed: displaced vs. non-displaced area
coordinate.
While the code duplication is often to be avoided, sometimes it is
more clear than a centralized place with a lot of arguments passed
to a function. We can have a pass of de-duplication later on, and
make a better decision, but for now restore user level behavior to
what it is expected to be.
Pull Request: https://projects.blender.org/blender/blender/pulls/111425
Call functions directly in lambdas rather than passing their
arguments in a separate void * argument. This can be changed
more in the future to move callback arguments out of smaller
structs.
The stroke mode of the eraser only tests distance with segments of the strokes, so it does not take into account strokes that only have one point, and thus no segment. This patch fixes the issue by testing if the point is inside the eraser in the case of a one-point stroke.
Pull Request: https://projects.blender.org/blender/blender/pulls/111387
Include counts of some headers while making full blender build:
- BLI_color.hh 1771 -> 1718
- BLI_math_color.h 1828 -> 1783
- BLI_math_vector.hh 496 -> 405
- BLI_index_mask.hh 1341 -> 1267
- BLI_task.hh 958 -> 903
- BLI_generic_virtual_array.hh 509 -> 435
- IMB_colormanagement.h 437 -> 130
- GPU_texture.h 806 -> 780
- FN_multi_function.hh 331 -> 257
Note: DNA_node_tree_interface_types.h needs color include only
for the currently unused (but soon to be used) socket_color function.
Future step is to figure out how to include
DNA_node_tree_interface_types.h less.
Pull Request: #111113
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
With the end goal of simplifying ownership and memory management,
and allowing the use of `get_name` in contexts without statically
allocated strings, use `std::string` for the return values of these two
operator type callbacks instead of `const char *` and `char *`.
In the meantime things get uglier in some places. I'd expect `std::string`
to be used more in the future elsewhere in Blender though.
Pull Request: https://projects.blender.org/blender/blender/pulls/110823
`OperatorType.get_name` callback is supposed to return strings directly
usable in the UI, i.e. translated if needed.
Several callbacks did not, noticiably the generic
`ED_select_pick_get_name` and `ED_select_circle_get_name` ones.
And the `sculpt_color_filter_get_name` was not using available RNA
helpers for enum items has it should have.
Finally, `RNA_property_enum_name_gettexted` and
`RNA_property_enum_item_from_value_gettexted` were also not using the
optimal higher-level translation API.
Noticed while reviewing !110776.
It is a common practice in gamedev to rely on coding various data into
the alpha channel of the mesh and there was no way to preserve that when
using the `Set Vertex Colors` operator (would always sets the Alpha component to '1').
Now add an "Affect Alpha" option (similar to what we have for brushes)
and when that is disabled, existing alpha is locked.
Fixes#110014
Pull Request: https://projects.blender.org/blender/blender/pulls/111002
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
Falk David
Hans Goudey
Philipp Oeser
Sergey Sharybin
Campbell Barton
Jeroen Bakker
Christoph Lendenfeld
Hans Goudey
Pratik Borhade
Germano Cavalcante
Jacques Lucke
Petar Dosev
Harley Acheson
Amelie Fondevilla
Aras Pranckevicius
Bastien Montagne