Remove the checks for region size in operator_markers_region_active as
that interferes too much. The only thing really interfering with
playhead movement when the area gets too narrow is MARKER_OT_select. So
this PR adds a new poll function for that in particular. That allows a
lot of simplification.
Pull Request: https://projects.blender.org/blender/blender/pulls/137399
Other changes include:
- Replace buffer out of bounds check with an assert
(it was only done for the byte).
- Step over pixels on each X span
instead of calculating the offset for each pixel.
- Use const variables.
Paths were checked for being at least 3 characters in length
before being added to FS_CATEGORY_OTHER.
It looks like this was originally done to prevent the preferences
attempting to add "//" paths which is now handled by `BLI_path_is_rel`.
As it happens the old logic prior to [0] was incorrect and asserted
if textures was set to "//textures" for example.
Now only check the path isn't empty.
[0]: 968f156fae
Excluding "/boot" mount point would also exclude directories
beginning with boot, without being a sub-directory.
Resolve by adding a version of STRPREFIX that delimits on null
terminator or slash.
Note that moving to the templated versions of array allocation functions
in [0] caused integer overflow regressions because multiplying by the
`sizeof(type)` caused the following values to be cast to a size_t.
[0]: e85ebb24fe
For Text Objects make sure we don't render a glyph for tab or other
control characters. Return nothing for carriage return and line feed,
and treat the others as a space character.
Pull Request: https://projects.blender.org/blender/blender/pulls/137374
When Timeline (and similar editors) is reduced to a just the height of
two headers you can still change the play head. Except if you have any
markers and then marker selection operator interferes. This PR sets a
minimum area height for marker operations. This minimum differs if you
hide the header.
Pull Request: https://projects.blender.org/blender/blender/pulls/137312
Previously, the BVH bounds were updated with a top-down approach
starting at the root. As explained in #136471, algorithms that visit
every node of the tree can become a bottleneck when sculpting high-res
meshes.
This patch refactors `flush_bounds_to_parents` by using a bottom-up
approach starting from the dirty leaf nodes. This requires calculating
and storing the parents of the nodes during the BVH build.
The change reduces the overhead measured in #136471 to near zero. The
same tests give the following results:
| Radius | Node Ratio | Speedup |
|--------------|---------|------------|
| 0.10m | 297 | 1.25x |
| 0.25m | 297 | 1.23x |
| 0.50m | 551 | 1.18x |
| 1.00m | 1930 | 1.13x |
where node ratio is the ratio between total nodes and nodes affected by
the brush. For reference, typical ratios when sculpting something like
a character are very roughly:
- tens when sculpting main forms
- low hundreds when sculpting secondary forms
- high hundreds to thousands when sculpting tertiary details
Pull Request: https://projects.blender.org/blender/blender/pulls/137019
Import the initial set of rest transforms as the Armature's rest pose,
even if there's no animation for the bones. The rest transforms are
already being written out during export.
Pull Request: https://projects.blender.org/blender/blender/pulls/135079
* Switches `Sculpt` for `Brush` since the former was just used to access
the latter.
* Simplifies the code to a single ternary.
* Renames and moves the method into the ed::sculpt_paint namespace
Pull Request: https://projects.blender.org/blender/blender/pulls/137368
For various purposes we traverse the computation done by a node tree (e.g. for
gizmos and socket usage infeferencing). For that we generally have to keep track
of the compute context we're in at any given time. During the traversal, it's
common to enter and exist the same compute contexts multiple times. Currently,
we'd always build a new compute context when that happens. That happens even
though the old one is generally still around, because other data may reference
it. This patch implements a `ComputeContextHash` type that avoids rebuilding the
same compute contexts over and over again.
I'm considering to also replace the usage of `ComputeContextBuilder` with this
cache somehow, but will see how that works out.
The reason I'm working on this now is that I have to traverse the node tree a
bit again to find where closures might be evaluated. I wanted to be able to
cache the compute contexts for a while already.
Pull Request: https://projects.blender.org/blender/blender/pulls/137360
The issue is the following:
- The stabilized normal for the main pass is calculated in
`calc_brush_plane`
- The normal is (wrongly) recalculated in `update_sculpt_normal`. This
is a common problem that other brushes have. The specific issue with the
Plane brush is that the recomputed normal is not stabilized.
- For symmetry passes, this non-stabilized normal is then assigned to
the brush in `calc_brush_plane`
This PR fixes the issue by explicitly returning false in
`sculpt_brush_needs_normal` when the Plane brush is used. A more proper
refactor would be needed, but this can easily be ported to 4.4.
Pull Request: https://projects.blender.org/blender/blender/pulls/137271
Use `blender::Stack` instead of `BLI_Stack`. Theoretically this can
improve performance because it makes use of inlining to remove function
call overhead and give the compiler more information. I observed a build
time improvement of about 4%, from 1156 to 1113 ms with 30k cube objects.
Notably, now `deg_graph_flush_visibility_flags` doesn't call any
non-inlined functions.
Pull Request: https://projects.blender.org/blender/blender/pulls/137355
This commit renames the `types.hh` file to `brushes.hh` as an attempt to
make brush implementations more independent and begin to unwind and
remove much of the logic in `sculpt.cc`.
As a first step, this moves the node mask calculation exposed for the
plane brush into `plane.cc` and exposes the function header into
`types.hh`.
Pull Request: https://projects.blender.org/blender/blender/pulls/137020
They are actually already some literals with the `f` suffix
that are in our shader codebase and we never had problem in
the past 5 years (or even 8 years).
So I think it is safe to do and improves convergence of codestyles.
Pull Request: https://projects.blender.org/blender/blender/pulls/137352
The goal is to log information about which closures are evaluated where. This
information is not exposed in the UI yet, but will be needed to be able to debug
the evaluation and inspect socket values within closures.
Pull Request: https://projects.blender.org/blender/blender/pulls/137351
I observed allocation becoming a bottleneck when building the depsgraph
with scenes with many simple data-blocks. One of the main culprits was
the struct that encodes relations between nodes in the graph.
Instead of allocating each `Relation` with a separate allocation call,
combine them into a `LinearAllocator`. That is must faster because it
allocates in large chunks and just bumps an offset on each allocation.
In a test file with 30 thousand cube objects, I observe a 1.18x
improvement in depsgraph evaluation time, from 1370 to 1163 ms.
The depsgraph isn't completely re-allocated when it's rebuilt, so the
allocator added in this PR has to be cleared manually. In the future,
it can be used for other structs or potentially strings.
Pull Request: https://projects.blender.org/blender/blender/pulls/137303
A couple of memory leak fixes for the vulkan backend.
We increment the submission_id on render_graphs upon reset. This
triggers cleanup of anything tracked as a VKResourceTracker. Notably
uniform buffers created for push constant fallbacks. This fixes a memory
leak that was accumulating VKUniformBuffers every frame without cleaning
them up.
Reset resource pools when a swapchain image is presented. This ends up
calling vkResetDescriptorPool, freeing up descriptor set resources. This
fixes a memory leak that was accumulate descriptor sets and pools over
time without freeing them.
Pull Request: https://projects.blender.org/blender/blender/pulls/137305
On certain platforms the 3d cursor wasn't visible. The reason was that
the shader read garbage in `gpu_attr_1_fetch_unorm8` and interpreted the
data to be packed, resulting in loading incorrect colors.
Pull Request: https://projects.blender.org/blender/blender/pulls/137336
Point count is missing in object and sculpt mode for Curves object.
Added an extra if block that handles this case. Added a new variable
`totcurvepoints` to track curve points count. Otherwise it is aggregated with
other points count (eg. mesh) which result in wrong number in status bar.
Pull Request: https://projects.blender.org/blender/blender/pulls/137199
As mentioned in #132028, search box is intentionally skipped for lib
override hierarchy view mode of outliner. But search filtering from
previous mode still builds the tree with searched elements. Added a new
function that checks the outliner view mode. If it's lib
override-hierarchy, skip search filtering.
See images attached in PR description.
Pull Request: https://projects.blender.org/blender/blender/pulls/137086
Remove long-deprecated constraints that will likely never be
implemented in this form.
- Rigid Body Joint Constraint was removed in 2.80, but some references
remained in the code. Versioning code was written that tried to
remove them on load, but since constraint initialization code sets
the type to CONSTRAINT_TYPE_NULL before versioning gets a chance,
the versioning code ended up never running. This has all been
removed.
- Python/Script Constraint never worked since 2.50 and showed an error
message in the UI panel.
These constraints now load as 'null' constraint, as seems to be
(looking at the code) the way that Blender currently deals with
removed constraint types. These still show up in the outliner and
python API, but have no UI panel. Removing such constraints completely
will be left for another time, as it is beyond the scope of removing
these two specific constraint types.
Pull Request: https://projects.blender.org/blender/blender/pulls/136672
When a stroke has a gradient fill material that starts with a color with
zero alpha, the tint modifier would behave as if it's not effective at
all, this is caused by referencing source material color only with the
starting color in this case, and since the alpha is zero, the tint is
applied wrongly. Now use average color of start and end color of the
gradient to mix with the tint modifier color.
Note that this isn't technically correct still, since material gradient
is computed in the shader, and tint modifier isn't able to get the
acutal fill color at a given vertex (especially for the radial gradient
case) however the result of this patch looks visually good enough, and
users can always set all alpha to 1 when they feel the color is off.
Pull Request: https://projects.blender.org/blender/blender/pulls/134549
