Implements the Butterworth Filter
(https://en.wikipedia.org/wiki/Butterworth_filter) for smoothing FCurves.
This filter is ideal for smoothing dense data, like motion capture recordings.
It has the advantage of keeping the shape of the curve
intact while reducing minimal fluctuations.
The disadvantage is the impulse response has a twang,
meaning extreme spikes cause fluctuations to either side.
The implementation is based on the GPL code found here:
https://exstrom.com/journal/sigproc/dsigproc.html
In order to avoid phase shifting, the filter is run forward and backward,
effectively doubling the filter order.
The Redo panel offers the following options
* Frequency Cutoff: 0-n value, where 0 means it cuts everything
so the curve will become straight, the max value is the Nyquist frequency
and depends on the frame rate and the "Samples per Frame" option
* Filter Order: Higher values mean the frequency cutoff is steeper
* Samples per Frame: Before the filter is applied, the curve is resampled
at this interval to avoid errors when there are uneven spaces between frames.
If the keys are on subframes, e.g. a 60fps file in a 30fps scene, increase this value to 2
* Blend: 0-1 value to blend between the original curve and the filter result
* Blend In/Out: The number of frames at the start and end for which
to blend between the filtered and unfiltered curve.
This can help reduce any resulting jumps in the animation at the selection border
The operator can be called from the Key menu. (Key->Smooth->Butterworth Smooth)
Pull Request: https://projects.blender.org/blender/blender/pulls/106952
This formats code that is disabled using `#if 0`. Formatting was achieved
by temporarily changing `#if 0` to `#if 1 /*something*/`, then formatting,
and then changing it back to `#if 0`.
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
There's quite a few libraries that depend on dna_type_offsets.h
but had gotten to it by just adding the folder that contains it to
their includes INC section without declaring a dependency to
bf_dna in the LIB section.
which occasionally lead to the lib building before bf_dna and the
header being missing, while this generally gets fixed in CMake by
adding bf_dna to the LIB section of the lib, however until last
week all libraries in the LIB section were linked as INTERFACE so
adding it in there did not resolve the build issue.
To make things still build, we sprinkled add_dependencies wherever
we needed it to force a build order.
This diff :
Declares public include folders for the bf_dna target so there's
no more fudging the INC section required to get to them.
Removes all dna related paths from the INC section for all
libraries.
Adds an alias target bf:dna to signify it has been updated to
modern cmake
Declares a dependency on bf::dna for all libraries that require it
Removes (almost) all calls to add_dependencies for bf_dna
Future work:
Because of the manual dependency management that was done, there is
now some "clutter" with libs depending on bf_dna that realistically
don't. Example bf_intern_opencolorio itself has no dependency on
bf_dna at all, doesn't need it, doesn't use it. However the
dna include folder had been added to it in the past since bf_blenlib
uses dna headers in some of its public headers and
bf_intern_opencolorio does use those blenlib headers.
Given bf_blenlib now correctly declares the dependency on bf_dna
as public bf_intern_opencolorio will get the dna header directory
automatically from CMake, hence some cleanup could be done for
bf_intern_opencolorio
Because 99% of the changes in this diff have been automated, this diff
does not seek to address these issues as there is no easy way to
determine why a certain dependency is in place. A developer will have
to make a pass a this at some later point in time. As I'd rather not
mix automated and manual labour.
There are a few libraries that could not be automatically processed
(ie bf_blendthumb) that also will need this manual look-over.
Pull Request: https://projects.blender.org/blender/blender/pulls/109835
Locked `FCurves` had 2 visual issues
* the dashing is so short it just creates visual noise
* keyframes are drawn in white looking like they are selected
This PR changes this by
* Increasing the dash width
* Keyframes are drawn in black on locked curves
* To indicate that they can't be selected, draw them in a X shape
* To further reduce visual noise, locked curves no longer draw thicker when selected
This is part of the changes discussed in this design task #104867
Pull Request: https://projects.blender.org/blender/blender/pulls/106052
- "Front"/"Back": 'put something at the front/back' or 'the front/back
face of something'. (e. g. the Empty Image options, Depth and Side
option, both use the same strings as enum, which should be avoided
in some languages).
- "Flip": invert, as in normals, or mirror, as in an image.
- "Path": a path to a resource, in general a file but sometimes a
datablock, as opposed to a trajectory in space.
- "Join": disambiguate for the Grease Pencil operator, which may use a
different word as that for meshes.
- "Wave": an ondulating motion, as opposed to a fluid dynamics motion.
- "Step": can mean the distance between two things, or a number of
times to do something. In this case it is better to use the plural.
- "Edge": generally the edges of a mesh, but can also mean edge
detection. Additionally, it was used for the option to enable
Freestyle. This was changed to "Use Freestyle".
- "Boundary": the limit of a grease pencil drawing for filling
purposes, as opposed to the external limit of a (non-manifold) mesh.
- "Rotations": can be translated to something like "Turns", in the
context of a spiral.
Pull Request: https://projects.blender.org/blender/blender/pulls/108213
No functional changes
In preparation to tackle the following 2 Todos
* TODO: view scale should factor into this someday too...
* TODO: optimize this to not have to calc stuff out of view too?
I did the following cleanup
* extracted drawing code for `BEZT_IPO_BEZ` into a separate function
* extracted code that calculates the resolution between 2 points into a separate function
* cleaned up comments
* renamed variables to have a more telling name
* moved variables closer to where they are used
* added `const` where possible
Pull Request: https://projects.blender.org/blender/blender/pulls/108748
The graph editor has the function to hide the display of FCurves and to only draw keyframes on selected curves.
Both options were not respected when executing the frame jump operator,
meaning it would jump to potentially hidden keyframes.
This patch adds a new operator that is specific to the Graph Editor and that respects those features.
The only possible issue that could arise from this is a slight confusion for the user
why they behave differently between editors.
Especially with only the Graph Editor and the 3D view open.
In general I think it's an improvement and follows the "you can only modify what you see" mantra in blender
Also
Resolves#97701
Pull Request: https://projects.blender.org/blender/blender/pulls/108549
This PR changes the ranges of some of the operators in the Graph Editor to be more logical
The following operators have been modified to with a range of -1/1 with the default of 0
* Blend to Neighbor
* Breakdown
* Ease
This is a breaking change because python calls to these operators will now yield different results
(e.g. Blend To Neighbor at 0 does nothing now, while before it did blend to the left neighbor)
Pull Request: https://projects.blender.org/blender/blender/pulls/107173
No functional changes.
`TFM_TIME_DUPLICATE` is basically the `TIME_TRANSLATE` or `TRANSLATE`
modes.
The difference is that `TFM_TIME_DUPLICATE` merge duplicates keyframes
at the end of the operation.
It is an unexposed mode in python and promotes code duplication.
It has a similar initialization to `TIME_EXTEND` which redirects to
`TIME_TRANSLATE` or `TRANSLATE` depending on the spacetype.
As it is dependent on other modes (as well as `TIME_EXTEND`), it makes
things a bit more confusing.
There's no real benefit to creating a new internal mode just to
indicate this small change (merge duplicates).
So indicate in another way (by properties) that you want to merge
duplicate keyframes.
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
The usage of the lib pointer was cryptic to say the least, it was
essentialy used to allow or not local IDs results in the mapping
old_id_pointer -> new_id_pointer lookup result.
Now:
- Explicitely pass a boolean to allow or not local ID as result in
lower-level code.
- Pass the 'self ID' pointer instead of its library to the whole
liblinking code (that was already the case in a few places).
Note that naming of the 'self id' pointer is currently very inconsistent
throughout the readfile liblink code, this will have to be cleaned up in
a separate step later. For now, `self_id` has been chosen for new code
as it matches the terminology in lib_query code.
The later change can also allow finer handling of lookup on undo, based
on how it was re-read (or not), should the need for this arise.
There was even one case in BLI ListBase tests!
Order was opposite of the one expected by the BLI ListBase code... Not
sure how, but this did not cause any issue apparently? But would expect
it to at least affect the order in which items in the list would be
iterated.
- The official spelling of FFMPEG is FFmpeg (upper, then lower case).
- The normal vector copy and paste operators shoud be singular because
they can only be used on a single element.
- The "Parent File" file browser operator goes up one level in the
file hierarchy. It should be called "Parent Directory", like the
current description "Go to the parent directory".
- "Mass Vertex Group" used to define the mass, but was reused at some
point and now actually defines cloth pinning so it should be called
"Pin Vertex Group", as in the UI.
- The Transformation constraint's Map To Type suffered from a
typo (probably of -> on).
- "Fall-off" is more commonly spelled "Falloff".
- "Effected" should really be "Affected" in this case.
- Rephrase the descriptions for the curve painting tools drawing
plane, which did not seem to match what the settings do. Namely,
they allow selecting in which plane to draw curves using the Curve
Draw tool.
Reported by @Joan-Pujolar in #43295:
- Force exporting animation on every objects [objects singular]
- Color of the interface widgets text insertion cursor (caret) [delete
interface widgets]
- Index of active aov [AOV in uppercase everywhere else]
- Does this tool use an painting canvas [an]
- This script was written Blender version %d.%d.%d ["for" missing
before "Blender"]
- [fcurve -> F-curve]
- unknown error stating file [statting]
- Offset into each stroke before the beginning of the dashed segment
generation [Two spaces between of and the]
- Find the nearest element in the a group. [either "the" or "a"]
Pull Request: https://projects.blender.org/blender/blender/pulls/107699
The current implementation goes like this
* default to a 0-1 range
* you can set `is_bidirectional` to get a -1/1 range
* if the slider is bidirectional the overshoot goes both ways, otherwise only on the positive side
The issue is that it is not possible to have a 0-1 range but overshoot both ways.
This is useful for example on the "Blend to Default" operator, where 0 means current position and 1 default.
But overshoot also makes sense for this operator since the other way just scales away from default.
So this patch:
* removes `is_bidirectional`
* adds `float range[2]` to `tSlider` and a setter for it
* rewrite some logic to handle arbitrary ranges
* split the `allow_overshoot` flag into one flag for either side
Pull Request: https://projects.blender.org/blender/blender/pulls/107406
This addresses #95855 by prioritizing the selection of keys in the following order:
1. Keys on the active curve.
2. Keys on any selected curve.
3. Other keys.
Additionally, this fixes an as-yet unreported issue where you couldn't select the main vertex of a key if it was overlapping with another one and one or more of its handle vertices were already selected. This was due to the selection status of a key and its handles not being properly considered separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/107223
The slider operators in the Graph Editor were missing operator flags for the cursor wrapping to work.
I've added it to the operators that allow overshoot, because for those it is really important to have no limits on scrolling.
Pull Request: https://projects.blender.org/blender/blender/pulls/107435
In some cases comments at the end of control statements were wrapped
onto new lines which made it read as if they applied to the next line
instead of the (now) previous line.
Relocate comments to the previous line or in some cases the end of the
line (before the brace) to avoid confusion.
Note that in quite a few cases these blocks didn't read well
even before MultiLine was used as comments after the brace caused
wrapping across multiple lines in a way that didn't follow
formatting used everywhere else.
In most of the operators the code that loops through the FCurve segments and draws the status header were pretty much identical.
To combat that, create abstract helper functions that can be used.
They are not useful in all cases, e.g. the blend to default operator needs a bit of special code.
Pull Request: https://projects.blender.org/blender/blender/pulls/107170
A buffer is a technical term most often referred to using the metaphor
of a "clipboard" in applications. However, the "clipboard" is usually
the system clipboard, used to carry data accross applications. To
avoid confusion, this replaces "clipboard" by "internal clipboard"
when not dealing with the system clipboard.
In addition, a few places still used the "[copy/paste] buffer"
terminology, so they are replaced with "internal clipboard as well.
The replacement from "[copy/paste] buffer" to "clipboard" was
undertaken in previous commits da6d6f99a8, 14b60c3a1c. This
commit should tackle the remaining occurrences.
Pull Request: https://projects.blender.org/blender/blender/pulls/106060
When normalization is enabled in the Graph Editor,
the area outside the -1/1 range on the y axis isn't meaningful.
To visually represent that this patch greys out that area
just as it does with anything outside the current frame range.
Pull Request: https://projects.blender.org/blender/blender/pulls/106302
The insert key operator allowed to insert a keyframe on all selected FCurves
and on the Active FCurve at cursor value.
But it didn't allow to insert a keyframe only on the active FCurve.
This patch adds that. It is available in the redo panel and under Key->Insert Keyframes (which can also be called with the I hotkey)
Pull Request: https://projects.blender.org/blender/blender/pulls/106307
The goal is to solve confusion of the "All rights reserved" for licensing
code under an open-source license.
The phrase "All rights reserved" comes from a historical convention that
required this phrase for the copyright protection to apply. This convention
is no longer relevant.
However, even though the phrase has no meaning in establishing the copyright
it has not lost meaning in terms of licensing.
This change makes it so code under the Blender Foundation copyright does
not use "all rights reserved". This is also how the GPL license itself
states how to apply it to the source code:
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software ...
This change does not change copyright notice in cases when the copyright
is dual (BF and an author), or just an author of the code. It also does
mot change copyright which is inherited from NaN Holding BV as it needs
some further investigation about what is the proper way to handle it.
Bug introduced by c2c6707919
Fixing it by undoing the changes to the if statements
at the start of the FCurve drawing functions.
This keeps the intended behavior of the previous path, while fixing the drawing
Pull Request: https://projects.blender.org/blender/blender/pulls/106100
Add a Gaussian smoothing operator to supersede the current
smoothing operator in the graph editor.
Advantage over the current implementation:
* Supports modal operations
* Is independent of key density
* More options in the redo panel
* More predictable Impulse Response
Option in the redo panel to change
Filter Width: How far out on each side of a key the code checks
to average key values
Sigma: The shape of the bell curve, lower values make a sharper bell curve
reducing the smoothing effect.
Too High values will make the code behave like an average filter as the
curve in the -1/1 range will almost be flat.
On a technical note, the operator needs to store additional data when running in modal
to avoid allocating/deallocating data on every modal run.
For that reason the `tGraphSliderOp` struct has been extended with
`void *operator_data` and `void (*free_operator_data)(void *operator_data)`.
The former is the data and the latter is a function responsible for freeing that data.
Pull Request: https://projects.blender.org/blender/blender/pulls/105635
