- CTX_wm_region(C) must be NULL checked as it's not checked in the
poll function.
- Add back the removed flag, note it's dirty.
- Replace ternary operators with min/max.
Prefer the name 'hit_result' since 'result' was sometimes used for
a vector of GPUSelectResult and is often used a functions return value.
Use hit_results for the span/vector and hit_result for a single hit.
Also assign struct members for new GPUSelectResult as it reads better
and avoids depending on struct order.
These are just duplicates of the pointers in `SubdivCCG`, which are
already quickly accessible. Keeping track of the state is too complex
and bloats the responsibilities of the PBVH too much.
Parallelize the implementation and move constant checks out of hot
loops. Only push undo steps for PBVH nodes that actually have changed
hide status. Optimize the "show all" case to remove the hide attributes.
For timings, I recorded some information on a 16 million vertex mesh:
- Hide masked (1/4 of mesh): 171 ms to 33 ms
- Hide small box: 13 ms to 14 ms
- Show all with small box hidden: 226 ms to 10 ms
- Show with all visible: 173 ms to 0.36 ms
There are a few other visbility operators that aren't affected:
- SCULPT_OT_face_set_invert_visibility
- SCULPT_OT_reveal_all
- SCULPT_OT_face_set_change_visibility
In separate steps, they should be moved to use the same structure, or
maybe even removed in the case of "reveal all".
I expect the "gather, change hidden verts, scatter" steps for each node
could be made a bit more efficient, they do some redundant work.
But it was also a simple way to share a reasonable amount of code.
Use multithreading, plus make the non-float / non-separate luma
calculations faster by avoiding byte->float->byte conversions
back and forth.
On a 4K resolution sequencer display, time taken to calculate the
waveform (Windows, Ryzen 5950X):
- regular images: 127.0ms -> 6.4ms
- regular images, separate colors: 160.3ms -> 13.1ms
- float images: 86.2ms -> 11.1ms
- float images, separate colors: 162.9ms -> 17.4ms
This also fixes curious "one black pixel row" in the middle of the
waveform, which was caused by the code spreading 256 possible luma
values over "off by one" vertical range:
Pull Request: https://projects.blender.org/blender/blender/pulls/115579
The grease pencil draw tool would still do a lot of smoothing
even if the active smoothing factor was set to 0.0.
This was because the screen space coordinates were always pre-blurred
before being passed to the curve fitting. Even if the curve fitting
outputs a line that fits the input exactly, it would still use the pre
smoothed coordinates.
The fix makes sure to use the smoothing factor in the influence
of the pre-blur. This way, no pre-blur is used when the factor is 0
and the lines will be smoothed much less.
Note that we always do some smoothing to avoid artifacts such
as pixel-grid-aligned lines etc.
You could already do overshoot via the mouse, but it was arbitrarily
disallowed when entering values numerically. This simply lifts that
restriction so that numerical input is capable of the same things as
dragging the mouse.
Importantly, the operator slider code already appropriately clamps
both mouse and numerical input when needed. So the checks and clamping
removed in this commit simply aren't needed, and removing them just
makes numerical input get constrained exactly the same as mouse input.
Pull Request: https://projects.blender.org/blender/blender/pulls/115534
Selection logic in ed_object_select_pick mixed operations for
object mode & other modes, making it difficult to reason about.
Refactor so object mode selection is isolated to it's own block,
following conventions for SelectPick_Params used by all other selection
picking operators.
This makes it possible to remove a call to de-select all objects
which was redundant in most cases.
Pass-through selection allows select-drag not to activate an already
selected object - so an existing selection can be dragged without
changing the active/selection (see #96544) & [0],
This caused entering pose-mode to fail when selecting an armature
with "Lock Object Modes" disabled.
There is a logical conflict where pass-through is intended to keep the
current selection & active, which doesn't make sense when selecting the
armature should enter pose-mode (details in code-comments).
Resolve by disabling pass-through when the select action changes
the objects mode.
[0]: 618f39fca2
Sequencer timeline UI repainting is 3x-4x faster now, for complex
timelines. On Sprite Fright Edit data set, with whole timeline visible
(2702 strips), repainting the timeline UI with all overlay options
(waveforms, offsets, thumbnails etc.):
- Windows (Ryzen 5950X, RTX 3080Ti, OpenGL): 62ms -> 18.6ms (16FPS -> 54FPS)
- Mac (M1 Max, Metal): 39.8ms -> 11.5ms (25FPS -> 86FPS)
This is achieved by:
- Avoiding tiny GPU draw calls (i.e. drawing one quad a time), instead
batch all the quads / lines needed by the timeline display into
series of about-1000 quads per draw.
- For retiming keys display, batch their keyframe point drawing too.
- For audio waveform overlay display, change it to draw batched quads
instead of alternating between line strips and triangle strips. This
actually changes how the waveform looks like (implements #115274)
and fixes some visual issues with waveforms too.
- For fcurve overlays, also draw them as batched quads.
While at it, this also fixes an issue where while dragging strips over
other strips, their text labels would look as if they are behind the
background strips.
Pull Request: https://projects.blender.org/blender/blender/pulls/115311
`ED_view3d_win_to_ray_clipped_ex` requires `ray_end` when
`do_clip_planes` is true.
Since the snap code uses `ray_depth` instead of `ray_end`, the solution
is to always calculate the `ray_end` and convert to `ray_depth` when
necessary.
This avoids some duplication between the modifier and operator evaluation
contexts and also makes it easier to make independent from a specific
evaluation context (so e.g. the simulation nodes code shouldn't care whether
it's used from a modifier or operator.
Pull Request: https://projects.blender.org/blender/blender/pulls/115512
Use blender::Set which is similar but offsers better type safety
and likely better performance as well. The only remaining user
was the mesh edit mode knife tool, and replacing that usage
with `Set` and `Map` was straightforward.
Inlining the functions is simpler nowadays, since there are utility
functions to copy spans and tag the mesh caches dirty. Also use an
array instead of a raw pointer for multires.
Resolves#103789
The issue was that bone colors are only specified with 3 channels (RGB),
but they're stored as 4 channels for some reason. So the fourth bogus
channel gets initialized to zero by default, which was then being
interpreted as zero alpha in some drawing modes.
This fixes the issue by ensuring that the fourth unused channel always
gets initialized to 255, and therefore can be validly interpreted as an
alpha channel.
Pull Request: https://projects.blender.org/blender/blender/pulls/115477
Problem is the `UI_context_active_but_get()` lookup doesn't respect menu
regions, unlike the earier call to `UI_context_active_but_prop_get()`
(which is also used to validate the existence of an active button).
Using `UI_context_active_but_get_respect_menu()` instead would work, but
in fact the earlier lookup returns the active button if any, we just
didn't use that.
Some Editors like the Filebrowser or Spreadsheet set up custom masks for
scrollbars (they dont cover the whole region width or height, some rows
or colums are excluded here -- e.g. the "index" column in the
Spreadsheet), this was working fine for drawing, but mouse interaction
was ignoring these custom masks.
Symptoms were that clicking on the "focus bubble" of the scrollbar and
dragging would not result in smooth scrolling [because internally code
would assume the mouse was clicking outside], instead scroll by 1 'page'
was happening [was perceived as a massive lag]. Especially noticable
with many rows/columns (where the "focus bubble" gets small).
So for drawing (`UI_view2d_scrollers_draw`) this wasnt a problem, masks
were passed in for `view2d_scrollers_calc`.
But for interaction (`scroller_activate_init`) `view2d_scrollers_calc`
is called again and a NULL mask was passed.
The already set up rects need to be considered though, otherwise coords
for `mouse_in_scroller_handle` later are not compatible.
To fix this, use existing `View2D` rects fors scrollbars, and pass a
union of those as `mask_custom` to `view2d_scrollers_calc`.
NOTE: this can temporarily extend the `View2D` scrollbar rect by a
pixel, the next draw call will correct this again though.
Pull Request: https://projects.blender.org/blender/blender/pulls/114631
Related commit: 82aa300e1c / 5596f7982182aa300e1c made it so that if only linked images are used, painting
would be prohibited. But since painting in Material mode actualy paints
across all materials it could happen that one particular image is linked
whereas another image isnt. In this case, painting on the linked image
would not be prohibited.
Two issues:
- [1] logic in above commit(s) seems slightly wrong, we could still pass
the check for linked images (also no image here should also not result
in a positive check I think).
- [2] code in `project_paint_prepare_all_faces` would still work with
linked images in slots, so
-- `ProjPaintState` -> `image_tot` was incremented
-- `ProjPaintImage` was created
-- this then ends up in the undo push - and crashes on undo
So now [1] is rectified and for [2] we skip faces with associated linked
images.
In addition, slots with linked images are now also greyed out in the UI
(`VIEW3D_PT_slots_projectpaint`) to give some sort of hint. For the
future it would probably also be good to dissallow selection of such
paint slots, but that is for another commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/115263
