The formats was not using the correct attribute type.
Fixes assert in graph drawing and potential assert in cursor drawing
Fixes assert in sequencer and file browser
The root cause of this bug can be traced to:
- `ANIM_nla_mapping_get(ac, ale)` conditionally returns an `AnimData *adt`.
- This can be `nullptr` in various cases, depending on the editor (in `ac`) and
the type & source of data (in `ale`).
- This `nullptr` has different meanings:
1. There is not enough information to return an `adt` (like `ac` or `ale`
being `nullptr` themselves).
2. NLA time remapping should not be done. For example for NLA control F-Curves
(like animated strip influence), or Grease Pencil (because that doesn't use
the NLA).
- The above-returned `adt` is passed to other functions. Some of them are aware
of the "`nullptr` means no NLA time remapping" scenario, and gracefully handle
it. Other code, however, just gets "an adt" from the caller and handles it as
normal (and likely crashes on `nullptr`). Other cases start out as the first,
but somewhere in the call stack shift over to the second.
The approach taken in this PR to fix the bug is to (generally) stop signaling
"do not use NLA time remapping" via `adt = nullptr`, and instead explicitly
indicate/check whether remapping should be done.
In most cases this means passing a `bAnimListElem *` instead of an `AnimData *`,
because the former has the information needed to determine if time remapping
should be done or not. However, in some cases there is no `bAnimListElem *` to
pass, and instead other information determines whether remapping is needed. In
those cases we add a `bool` parameter or field in the appropriate place so that
calling code can explicitly indicate whether remapping should be done or not.
To accomplish this a variety of functions have been added to help handle things
correctly. Of particular note:
- `AnimData *ANIM_nla_mapping_get(ac, ale)` (that conditionally returned an
`adt`) has been removed entirely in favor of the new
`bool ANIM_nla_mapping_allowed(ale)` function that simply returns whether
nla remapping should be done or not.
- `ANIM_nla_tweakedit_remap(ale, …)` has been added, which wraps
`BKE_nla_tweakedit_remap(adt, …)` and only performs the remapping when
`ANIM_nla_mapping_allowed()` indicates that it's allowed.
- `ANIM_nla_mapping_apply_if_needed_fcurve(ale, …)` has been added, which is an
alternative to `ANIM_nla_mapping_apply_fcurve(adt, …)` that also only performs
the remapping when `ANIM_nla_mapping_allowed()` indicates that it's allowed.
Note that even with this PR there are still a couple of places remaining that
use `adt = nullptr` to indicate "don't remap", because they appear to be correct
and would require larger changes to make explicit. In those cases comments have
been added to explain the situation, with a reference to this PR. In the future
we way want to take the time to change those as well.
Also of minor note: this PR moves the definition of the type `slot_handle_t`
from ANIM_action.hh to BKE_action.hh. This is due to `BKE_nla.hh` (which needs
that definition) now being included directly and indirectly in a lot more
places. Moving the definition to BKE_action.hh prevents all of those new places
from gaining dependencies on the animrig module.
Co-authored-by: Sybren A. Stüvel <sybren@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/130440
The issue was that the key bounds for determining if a key can be skipped
were initialized incorrectly.
The order of `rctf` is [xmin, xmax, ymin, ymax] but the values were given as
[x, y, x, y].
The correct order is [x, x, y, y]
Pull Request: https://projects.blender.org/blender/blender/pulls/126554
The drawing code in the Graph Editor reduces the points drawn by checking the pixel distance.
The calculation for the pixel distance didn't take the normalization into account though, so
in certain scenarios points would be skipped that shouldn't be skipped.
The fix is to pass the normalization factor into the pixel distance calculation.
Pull Request: https://projects.blender.org/blender/blender/pulls/121070
No functional changes.
This modifies the function `get_bounding_bezt_indices` to return an `IndexRange` instead of an `int2`.
With that it is possible to use the C++ for loop syntax.
The function is renamed to `get_bounding_bezt_index_range` to represent its return type.
Pull Request: https://projects.blender.org/blender/blender/pulls/120786
While the drawing code already skipped drawing any key points that are not in view,
it did that with an `if` check within the `for` loop. This can be speed up quite a bit
by calculating the bounding indices beforehand and only iterating that range.
| - | Before | After |
| - | - | - |
| `draw_fcurve_selected_keyframe_vertices` | 44850ns | 3194ns |
| `graph_main_region_draw` | 32ms | 21ms |
Test file used
https://download.blender.org/ftp/sybren/animation-rigging/heavy_mocap_test.blend
Pull Request: https://projects.blender.org/blender/blender/pulls/120521
The issue is that when applying filters, the list of channels shrink, but the `View2D` isn't updated accordingly.
When you move the viewport, the channels would jump back into view but not before.
The total height of the channel stack is computed every frame,
and the issue is fixed by calling the `UI_view2d_curRect_clamp_y` after that.
Since this has to be done before `UI_view2d_view_ortho` is called, I had to extract
the height calculations into the caller function.
I thought about making a generic function for all 3 editors but they were too different
to meaningfully do that.
I removed the fix that stopped the channels going off screen when using the cursor to scroll,
since the new logic already does that.
Note: while the report only mentions the Dope Sheet, this fix is applied to
the Graph Editor and NLA editor as well since they had the same issues. This PR fixes them all.
Also fixes#46649
Pull Request: https://projects.blender.org/blender/blender/pulls/118006
Along with the 4.1 libraries upgrade, we are bumping the clang-format
version from 8-12 to 17. This affects quite a few files.
If not already the case, you may consider pointing your IDE to the
clang-format binary bundled with the Blender precompiled libraries.
No functional changes.
`ANIM_get_normalization_flags` had the argument type of `bAnimContext *`.
That made it more difficult than it needs to be to reuse that function.
Pass a `SpaceLink *` instead since that is what the function actually uses.
Pull Request: https://projects.blender.org/blender/blender/pulls/114676
As people have pointed out, the changes to key drawing
in #106052 are not ideal under all conditions.
The fact that an X is drawn to indicate a key
can't be manipulated adds too much noise
on dense data and is generally confusing.
To combat that, the drawing style changed it back to dots,
but this time in gray ( the same color as disabled curves)
and slightly smaller.
This was discussed in the A&R module meeting on 2023-09-07
Pull Request: https://projects.blender.org/blender/blender/pulls/111986
The first keyframe's handle wasn't drawn due to the recent optimizations.
This PR fixes the issue by moving `prevbezt` out of the loop again.
That is needed due to the checks in within the loop having special cases
for the first loop where `prevbezt` is a `nullptr`
Was caused by #112126
Pull Request: https://projects.blender.org/blender/blender/pulls/112365
The drawing code of the keyframe handles had the same issue
as the curve drawing itself, namely that it drew everything even things out of view.
This patch uses the same logic introduced in #110301 to get the
bounding indices of the curve in the viewport and only draw those.
This does NOT improve the performance when fully zoomed out on large data.
Test setup: 6000f of dense key data on 62bones
I ran my test on a zoom level that had the Graph Editor display about 500 frames.
The numbers are per curve and ONLY the handle drawing functions.
| Before | After |
| - | - |
| ~300μs | ~53μs |
Pull Request: https://projects.blender.org/blender/blender/pulls/112126
Introduced with #110788
Because of the logic introduced there, the first key might not be drawn,
resulting in a wrong extrapolation line.
This fixes it by always adding the first point
Pull Request: https://projects.blender.org/blender/blender/pulls/112072
When viewing a curve with a lot of keys totally zoomed out,
the keys might be closer to each other than a pixel.
The code would still draw a line between them,
costing time in the draw code.
This PR skips any keys that are too close to each other in screen space.
## Performance
The setup: 62 bones with 6000f of animation keyed on every frame.
No keys displayed, just the curves.
| - | before | after |
| - | - | - |
| zoomed in | 11μs | 17μs |
| zoomed out | 55μs | 30μs |
So a small performance penalty when zoomed in in exchange for a big gain when zoomed out.
There is a small change in visuals when zoomed out a lot.
Because this change averages keys that are too close together,
it results in a small loss of high frequency detail.
## The logic
If `prevbezt` and `bezt` are too close it will not draw,
but extend a bounding box with `prevbezt` and `bezt` including handles if needed.
Eventually the keys will be far enough apart to draw.
At this point, draw the center of the bounding box and reset it.
Now because there could be the case where `bezt` in the
current loop is super far out (e.g 5 keys with 1f spacing and the 6th key is at f1000)
we need to recalculate the bounding box again.
In case the keys are far away, just draw normally.
If it is close still, the same process repeats.
Pull Request: https://projects.blender.org/blender/blender/pulls/110788
Recent patches added a variable `resolution_scale`
This variable defines how many points on the x or y axis to add.
However I find the name confusing.
Instead of that, change it to `pixels_per_unit`
and move the `points_per_pixel` factor
to `calculate_bezt_draw_resolution`
no functional changes
Pull Request: https://projects.blender.org/blender/blender/pulls/111037
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.
Before this patch, the drawing code iterated the FCurve to see if there are any
curve interpolation types that can't easily be drawn. (Sinusoidal, Bounce, etc)
If it found one, it would fall back to evaluating the FCurve.
That meant in the worst case scenario it would iterate the whole FCurve
before even starting to draw.
This PR unifies the drawing logic for FCurves no matter their interpolation type.
If it encounters a key type that it can't draw, it falls back to samples, but only
for the current key.
To clarify that it renames `draw_fcurve_curve_bezts` to `draw_fcurve_curve_keys`
Curves with modifiers are still drawn with samples.
## Performance
Test setup: 6000f of dense data on 62 bones.
Only measuring the average draw time **per curve**.
All measurements were done at the same zoom level.
| - | before | after |
| - | - | - |
| only beziers | 28μs | 13μs |
| only elastic | 90μs | 60μs |
| mix (~1/2 of the view with elastic) | 110μs | 24μs |
The performance boost with "only elastic" can be explained by the fact that per key I can skip 1 call to `evaluate_fcurve`. That is because I always start at an existing keyframe so I can use its position.
Pull Request: https://projects.blender.org/blender/blender/pulls/110764
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
In current blender, when drawing curves in the Graph Editor,
it always iterates over the whole curve.
From first to last vertex no matter what is shown on screen.
Instead of that, find the bounding keyframes and iterate within them.
Additionally to that, break apart the logic into two sections
* first iterate over keyframes and add `float2` into a `Vector`
* then iterate over all those points and draw them
The second optimization is to make the Bezier resolution
dependent on the keyframe distance in screenspace.
Previously it just went off the distance between keys in frames,
but that doesn't make sense if you are zoomed out.
## Performance Numbers
The following performance numbers are the
average time **per curve** on a mocap file of 6000f (each frame has a key).
The numbers were generated **without** showing keyframes to only focus
on the performance of this patch.
Also they are from a debug build, so they just make sense relative to each other
| - | before | after |
| - | - | - |
| zoomed in | ~1000μs | ~77μs |
| zoomed out | ~1000μs | ~430μs |
This only affects the actual curves.
Keyframe and handle drawing can likely still be improved
Pull Request: https://projects.blender.org/blender/blender/pulls/110301
The drawing code executed NLA mapping code
even though there were no tracks to be mapped.
Disabling this takes the `draw_fcurve` function
from ~1130μs to ~985μs (heavy example scene with dense data)
~13% faster
Of course this only applies when not using the NLA.
And the performance benefit is larger, the more curves are on screen
Pull Request: https://projects.blender.org/blender/blender/pulls/110306
This moves the remaining `.c` files in the following `editors` folders to C++:
`physics`, `screen`, `sound`, `space_buttons`, `space_file`, `space_graph` and `space_image`.
One exception is `fsmenu.c` which has platform specific issues on macos and
windows. E.g. the `Carbon/Carbon.h` include also declares a `Collection` type that collides
with ours.
Also see #103343.
Pull Request: https://projects.blender.org/blender/blender/pulls/109918
