Part of #91973
Moving the snapping code for the
* Graph Editor
* Action Editor
* and NLA editor
into the common system that lives on the scene.
This includes the Magnet icon for turning
snapping on and off.
The old settings translate to the new in the following way:
* `Frame Step` -> `Frame`
* `Second Step` -> `Second`
* `Nearest Frame` -> `Frame` + `Absolute Time Snap`
* `Nearest Second` -> `Second` + `Absolute Time Snap`
* `Nearest Marker` -> `Nearest Marker`
Since this moves the location of the snapping settings
from the editor to the scene, it changes the behavior.
Previously each editor could have different snapping
settings, where now they are all synced.
Pull Request: https://projects.blender.org/blender/blender/pulls/109015
For operators that allow overshoot it is important that the cursor wraps,
so the user is not limited by the bounds of the screen.
This was missed on a few of the latest additions.
Pull Request: https://projects.blender.org/blender/blender/pulls/111785
This is a combination of two PRs from Ares Deveaux: #106521 and #106522
This adds a new operator that allows shearing keys
based on the position of the segment ends.
By pressing `D` while the operator is in modal you can
switch if the operator takes the left or the right segment end as a reference.
Co-authored-by: Ares Deveaux <aresdevo@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/111735
The factor property of the "Blend to Ease" operator
in the Graph Editor had the same name and description as the "Ease" operator.
This patch fixes it and makes the description more accurate
Pull Request: https://projects.blender.org/blender/blender/pulls/111745
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
The `lib_link` callback cannot always be fully replaced/removed, as in
some case it is also doing some validation checks, or data editing based
on the result of lib_linking internal ID pointers.
The callback has been renamed for that purpose, from `read_lib` to
`read_after_liblink`. It is now called after all ID pointers have been
fully lib-linked for the current ID, but still before the call to
`do_versions_after_linking`.
This change should not have any behavioral effect. Although in theory
the side-effect of this commit (to split lib linking itself, and the
validation/further processing code) into two completely separated steps
could have some effects, in practice none are expected, and tests did
not show any changes in behavior either..
Part of implementing #105134: Removal of readfile's lib_link & expand code.
When using a slider it is possible to enter numbers for an exact value
However that input was capped between 0 and 1,
which is no longer correct since the range can be arbitrary.
Additionally it was divided by 100 because the slider
operator system assumed we'd be working with percentages.
This fixes both of these issues.
Pull Request: https://projects.blender.org/blender/blender/pulls/111269
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.
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
This PR blends the selected keyframes to an ease-in or ease-out curve.
The difference to the existing ease slider is that this one blends,
while the other snaps to the ease curve
Co-authored-by: Ares Deveaux <aresdevo@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/110566
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
The new keyframe jumping code for the graph editor did not respect the NLA strip offset.
This patch fixes that by applying `ANIM_nla_mapping_apply_fcurve`
Technical side note: `FCurve *` lost its constness due to that
Pull Request: https://projects.blender.org/blender/blender/pulls/110790
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
The cleanup of blenkernel last weeks , caused the house of cards to
collapse on top of bf_gpu's shader_builder, which is off by default
but used on a daily basis by the rendering team.
Given the fixes forward in #110394 ran into a ODR violation in OSL that
was hiding there for years, I don't see another way forward without
impeding the rendering teams productivity for "quite a while" as there
is no guarantee the OSL issue would be the end of it.
the only way forward appears to be back.
this reverts :
19422044eda670b53abe0f541db97cbe516e8c813e88a2f44c4e64b772f59547e7a31707fe6c5a57
The problematic commit was 07fe6c5a57
as blenkernel links most of blender, it's a bit of a link order issue
magnet. Given all these commits stack, it's near impossible to revert
just that one without spending a significant amount of time resolving
merge conflicts. 99% of that work was automated, so easier to just
revert all of them, and re-do the work, than it is to deal with the
merge conflicts.
Pull Request: https://projects.blender.org/blender/blender/pulls/110438
- "Rename Channels": only one channel can be renamed at a time, use
singular.
- "Copy Markers to Scene": rephrase erroneous operator description.
- "Axis tag names with": grammar.
- "Close or open the selected stroke adding an edge from last to first
point": "segment" is preferred to "edge" elsewhere in the context of
curves or Grease Pencil.
- "Number of subdivisions [points] by edge[s]": replace "by edge" with
"per segment" for the same reason.
- "Compatibility mode for SL, OpenSim...": expand to explain that SL
and OpenSim are respectively Second Life and OpenSimulator.
- "W/m^2" -> "W/m²". This symbol is widely supported and should be
preferred for exponentiation outside of code.
- "Effect on tracks which are tracked less than specified amount of frames",
"Effect on tracks which have a larger reprojection error":
Use "Affect" and "number" instead of "amount".
- "Hull curve" -> "Envelope". This is a calque from German Hüllkurve
meaning envelope.
- "Frquency Cutoff" -> "Frequency Cutoff" (typo)
- "Check if Select Left or Right": rephrase to "Based on Mouse
Position" as it better explains the action of the operator.
- "Make cut event if strip is not selected ..." -> even (typo)
- "Shear selected items along the horizontal screen axis":
Rephrase as this transform operator can act in many different axes.
- Tonemapping compositing node: the two algorithms "R/D Photoreceptor"
and "Rh Simple" only had names, but no description. Add ones
explaining at least the basic principle and where the names come
from.
- In the "Matte dilate/erode side" description for the Keying node's
Dilate/Erode socket, "side" was likely a typo for "size".
Reformulate the description to make it clearer, inspired by similar
ones.
- "Width of the blur edge" -> "Width of the blur for the transition";
"Edge angle" -> "Angle of the transition";
"Wipe direction" -> "Whether to fade in or out":
Better explains the sequencer wipe transition (inspired by the manual).
- OSL shaders now supported on some GPU backends.
- "Add a new repeat input and output nodes " -> "Add new" (typo).
Pull Request: https://projects.blender.org/blender/blender/pulls/110321
