Texture usage flag `GPU_TEXTURE_USAGE_MIP_SWIZZLE_VIEW`
was originally implemented and used too conservatively for many
cases in which the underlying API flags were not required.
Renaming to `GPU_TEXTURE_USAGE_FORMAT_VIEW` to reflect
the only essential use case for when a texture view is initialized with
a different texture format to the source texture. Texture views can
still be created without this flag when mip range or base level is
adjusted,
This flag is still required by stencil views and internally by the Metal
backend for certain feature support such as SRGB render toggling.
Patch also includes some small changes to the Metal backend to
adapt to this new compatibility and correctly capture all texture view
use-cases.
Related to #115269
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/115300
While drawing, the line beeing drawn would seemingly only update once
in a while. This was because there was a bug in the interpolation
function that would write the value being interpolated from
directly to the destination as the first value.
In our case, we only wanted to write new values (so
we need to exclude the first one).
Making sure the interpolation always excludes the value
interpolated from, fixes the drawing stutter issue.
This was only used in one place. Adding the name lookup to
`SCULPT_vertex_mask_get` is not good long term, but the use
of that function can be removed too.
Store paint masks as generic float attributes, with the name
`".sculpt_mask"`. This is similar to 060a534141, which made
the same change for face sets. The benefits are general
consistency, nicer code, and more support in newer areas
that deal with attributes like geometry nodes.
The RNA API is replaced with one created in Python. The new
API only presents a single layer as an attribute class, so it
should be simpler to use in general:
- Before: `object.data.vertex_paint_masks[0].data[0].value`
- After: `object.data.vertex_paint_mask.data[0].value`
Pull Request: https://projects.blender.org/blender/blender/pulls/115119
Avoid the need to call the separate `BKE_mesh_wrapper_minmax` function
that dealt with the edit mesh wrapper. This makes the API inconsistent,
since other mesh functions don't implicitly deal with the wrapper.
But the bounds are a bit of a special case anyway in regard
to the GPU subdivision wrapper already, and this is much more
convenient in the rest of the refactors for #96968.
Use float3, float3x3, and Array for data used for mesh crazyspace
calculation. Propagate the change wherever necessary to not add
more casting to the old C types.
Because `ObjectRuntime` (and therefore `DEGObjectIterData`) became
non-trivial structs, the code that swaps iterators for RNA depsgraph
object iteration had to be changed a bit to be more friendly to C++
memory semantics.
Pull Request: https://projects.blender.org/blender/blender/pulls/114998
Move object runtime data to a separate header and allocate it separately
as `blender::bke::ObjectRuntime`. This is how node, mesh, curves, and
point cloud runtime data is stored.
Benefits:
- Allow using C++ types in object runtime data
- Reduce space required for Object struct in files
- Increase conceptual separation between DNA and runtime data
- Remove the need to add manual padding in runtime data
- Include runtime struct definition only in files that require it
Pull Request: https://projects.blender.org/blender/blender/pulls/113957
Only converted value types in the structures.
The pointer values are left unchanged as it requires more careful look
to avoid possible alignment mismatch.
Function arguments are left unchanged as well.
Only float[3] is converted as the float[4] will likely need to be
converted to some C++ rotation class. And float[4][4] often did not
compile when change is only done in the header.
Pull Request: https://projects.blender.org/blender/blender/pulls/114636
Cleanup talked about in the previous semi-related PR, #114501
- saacos, saasin, sasqrt have been 100% identical to saacosf,
saasinf, sasqrtf since 2012.
- For all the above, there exist more intuitively named safe_acosf,
safe_asinf, safe_sqrtf that do the same thing, so switch all code to those.
Pull Request: https://projects.blender.org/blender/blender/pulls/114593
This commit removes knowledge about face sets from the PBVH,
and changes iteration over faces to not depend on the PBVH face
iterator abstraction. Though this adds slightly more boilerplate to
iteration over faces, it makes the whole process more data oriented
and allows use of index-based utilities like `gather` and `scatter`
in the mesh case, and simpler iteration over BMesh faces for
dynamic topology.
Setting face sets is now specialized per PBVH type in a few places
in a similar way. The general goal is to reduce branching and function
calls at the lowest level of hot loops, and to make code more aware
of the data structures it uses, both for performance and clarity.
Since the remaining uses of the face iterator are removed,
the iterator itself is removed too.
Related commits:
- 97f2b01ea9
- 756dea7ca1
- a6a2af5fdd
Pull Request: https://projects.blender.org/blender/blender/pulls/114417
Adds a new scene tool setting `use_grease_pencil_multi_frame_editing`.
The `foreach_*_drawing` functions are moved to the `ed::greasepencil` namespace in the editor, since they are now context sensitive and depend on the toolsetting. They are now named `retrieve_editable_drawings` and `retrieve_visible_drawings` and return
an array of drawings instead of calling a callback function.
Pull Request: https://projects.blender.org/blender/blender/pulls/114283
4e87b3004b made the logic to require all vertices in the face
to be covered by the brush. However, the behavior is closer to the non-
BMesh version if only one of the face's vertices needs to be in "inside".
Pair-reviewed in person with Sergey
These two values are already stored in the mesh, and they have no
relation to the PBVH's goal as an acceleration structure. Similar to
a6a2af5fdd, remove the values from the PBVH and
just access them from the mesh as necessary.
Pair-reviewed in person with Sergey
The implementation follows the logic of the face set brush for the
faces and grids type of PBVH, with the similar weak part of iterating
over entire mesh at the start of a stroke.
The difference in the behavior is that face needs to be fully covered
by the brush in order to have face set assigned to it (while for the
other types of the PBVH face gets assigned its face set if any of its
vertices are covered). The main reason for this is that this seems to
avoid boundaries being too wiggly.
The auto-masking is not fully integrated into this brush yet. Doing so
is possible, but seems to require deeper re-considerations of the way
how automasking accesses original data and how it is fetched from an
undo node. It worth noting that auto-masking is something that needs
to be looked into for all brushes to make it supported in the dynamic
topology mode.
Pull Request: https://projects.blender.org/blender/blender/pulls/113357
The last good commit was 8474716abb.
After this commits from main were pushed to blender-v4.0-release. These are
being reverted.
Commits a4880576dc from to b26f176d1a that happend afterwards were meant for
4.0, and their contents is preserved.
With two or more windows, edit-mode undo assumed it was
possible to load the undo state into the current scene.
When multiple windows are used this is not always the case.
Edit-mode undo steps now store the scene used to create them
which is used to read undo data back into this scene
(when it's shown in a window). Otherwise the current context is used.
When the object was transformed, the eraser would no longer work.
This was because the transformation of the positions to screen space
did not take the transforms into account.
This fix adds the transforms to the erasing operation.
When retrieving a color attribute to paint it, the layer data needs to
be unshared so that it doesn't modify data from separate meshes.
In the past I think we've unknowingly avoided this problem by porting
code to the new attribute API. I've been refactoring `PBVH` and
`SculptSession` to make that possible (removing the long-lived
layer pointers in the two structs). But that wouldn't fit as a bug fix.
In the meantime, make sure the color attribute data is un-shared
and separate "for read" and "for write" versions of the function.
Pull Request: https://projects.blender.org/blender/blender/pulls/114119
The goal is to make it possible to have more or less reliable way
to perform performance comparisons of changes in algorithms used
in dynamic topology.
This change allows to run Blender with the following arguments:
blender --log "sculpt.detail,pbvh.bmesh" --log-level 2
and see timing of dynamic topology flood-fill operation, as well as
individual timings of edge subdivision/collapsing.
Pull Request: https://projects.blender.org/blender/blender/pulls/114099
This should fix one of the remaining crashes while drawing.
The issue was that we would try to write to an out-of-bounds
memory location.
This fixes the issue and also cleans up the code a bit more,
adding more comments and using better names.
The drawing plane was at the world origin not the object origin.
This still needs to use the correct drawing plane in the future,
but it's a good step in the right direction.
In the draw tool in the `process_extension_sample` we would
create an `GSpanAttributeWriter` to initialize the default values for
the new points, but we would return early for curve attributes.
This return needs to happen before we create the `GSpanAttributeWriter`.
Ray Molenkamp
Jason Fielder
Hans Goudey
Falk David
Hans Goudey
Philipp Oeser
Pratik Borhade
Sergey Sharybin
Aras Pranckevicius
Campbell Barton
Brecht Van Lommel