Use a consistent style for declaring the names of struct members
in their declarations. Note that this convention was already used in
many places but not everywhere.
Remove spaces around the text (matching commented arguments) with
the advantage that the the spell checking utility skips these terms.
Making it possible to extract & validate these comments automatically.
Also use struct names for `bAnimChannelType` & `bConstraintTypeInfo`
which were using brief descriptions.
- Keying (keyframe insertion)
- Roughness (particle children)
- New image, collection, text (in menus)
- Parents (particles)
- Wrap (text)
- Light (add menu)
- Empty (volume add menu)
- Empty (empty add menu)
- Cycles (f-curve modifier)
- Drag (workspace tool type)
- Power (light intensity)
- Power (math nodes)
This last change also moves all math operations in nodes to the
ID_nodetree context. It's needed only for some operations, but we
can't be more granular here.
Also...
- Fix context extraction for interpolation mode headers in F-Curves
and GPencil interpolation operator
- Enable new translation: "Slot %d" in image editor
- Fix an English message in the node editor:
"Replace the input image's alpha channels by..." -> channel
Ref. T43295
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D15694
Rename and refactor several F-curve key manipulation functions, and move
them from `editors` to `blenkernel`.
The functions formerly known as `delete_fcurve_key`,
`delete_fcurve_keys`, and `clear_fcurve_keys` have been moved from
`ED_keyframes_edit.h` to `BKE_fcurve.h` and have been renamed according
to hierarchical naming rules.
Below is a table of the naming changes.
| From | To |
| -- | -- |
| `delete_fcurve_key(fcu, index, do_recalc)` | `BKE_fcurve_delete_key(fcu, index)` |
| `delete_fcurve_keys(fcu)` | `BKE_fcurve_delete_keys_selected(fcu)` |
| `clear_fcurve_keys(fcu)` | `BKE_fcurve_delete_keys_all(fcu)` |
| `calchandles_fcurve()` | `BKE_fcurve_handles_recalc()` |
| `calchandles_fcurve_ex()`| `BKE_fcurve_handles_recalc_ex()` |
The function formerly known as `delete_fcurve_key` no longer takes a
`do_fast` parameter, which determined whether or not to call
`calchandles_fcurve`. Now, the responsibility is on the caller to run
the new `BKE_fcurve_handles_recalc` function if they have want to
recalculate the handles.
In addition, there is now a new static private function called
`fcurve_bezt_free` which sets the key count to zero and frees the key
array. This function is now used in couple of instances of functionally
equivalent code. Note that `BKE_fcurve_delete_keys_all` is just a
wrapper around `fcurve_bezt_free`.
This change was initially spurred by the fact that `delete_fcurve_keys`
was improperly named; this was a good opportunity to fix the location
and naming of a few of these functions.
Reviewed By: sybren
Differential Revision: https://developer.blender.org/D15282
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
- Added space below non doc-string comments to make it clear
these aren't comments for the symbols directly below them.
- Use doxy sections for some headers.
- Minor improvements to doc-strings.
Ref T92709
When using FModifier `Restrict Frame Range`, the resulting influence was
zero being exactly on `Start` / `End` range borders (so borders were
**exclusive**).
This made it impossible to chain FModifers together (forcing the user to
specify values slightly below the desired border in following
FModifiers).
This is now corrected to be **inclusive** on Start / End range borders.
Before
{F10234864}
After
{F10234865}
Testfile
{F10234866}
In the case of touching open borders (so [frame A frame B] followed by
[frame B frame C]) both modifiers are evaluated (in stack order).
If the later modifier has full influence (and is not additive) this simply
means the result is the same as the later modifier's value.
If influences below 1 are used (or modifiers are additive) both modifier's
values are interpolated/added accordingly.
technical notes:
- this was caused by the introduction of FModifier Influence/BlendIn-Out
in rB185663b52b61.
- for comparison, see other occurrences of
`FMODIFIER_FLAG_RANGERESTRICT`.
- the following conditions in `eval_fmodifier_influence` for blend in/
out have been changed accordingly.
Maniphest Tasks: T85564
Differential Revision: https://developer.blender.org/D10401
This patch implements the list panel system D7490 for FCurve modifiers.
The UI layouts are updated to make use of subpanels and to be consistent
with the rest of the interface, and easier to understand.
See the differential revision for screenshots.
This commit also significantly cleans up the FModifier UI code, and
improves, mainly by replacing the old button creation code is with
the newer interface API using RNA. In turn there is a bit of complexity
added because each FModifier has a separate panel.
Although reordering of FModifiers was not implemented before, we get
drag and drop basically for free here, so it is also included.
As noted in some older to do tasks, FModifiers aren't evaluated
in perfect order, which may be a point of improvement for the future.
Differential Revision: https://developer.blender.org/D7997
Use common prefix as this collided with existing API's (eg BLI_voronoi).
Also expand some non-obvious abbreviations:
- 'g' -> 'generic'
- 'vl' -> 'variable_lacunarity'
- 'V' -> 'v3'
Note this only changes cases where the variable was declared inside
the for loop. To handle it outside as well is a different challenge.
Differential Revision: https://developer.blender.org/D7320
This also makes `IDP_CopyProperty` the "opposite"
of `IDP_FreeProperty`, which is what I'd expect.
Two refactoring steps:
* rename IDP_FreeProperty to IDP_FreePropertyContent
* new IDP_FreeProperty function that actually frees the property
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4872
Previously, when a fcurve modifier used storage,
many heap allocations were done.
This caused major slowdowns as described in T63656.
Furthermore, the storage usage was a special case only
used by the Cycles modifier. This refactor makes
storage usage the "normal" case.
That reduces the overall complexity.
The storage is stack allocated now.
The framerate on the provided test scene went up from ~5 fps to ~16 fps.
Reviewers: angavrilov
Differential Revision: https://developer.blender.org/D4701
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
Cyclic extrapolation is implemented as an f-curve modifier, so this
technically violates abstraction separation and is something of a hack.
However without such behavior achieving smooth looping with cyclic
extrapolation is extremely cumbersome.
The new behavior is applied when the first modifier is Cyclic
extrapolation in Repeat or Repeat with Offset mode without
using influence, repeat count or range restrictions.
This change in behavior means that curve handles have to be updated
when the modifier is added, removed or its options change. Due to the
way code is structured, it seems it requires a helper link to the
containing curve from the modifier object.
Reviewers: aligorith
Differential Revision: https://developer.blender.org/D2783
Noisy change, but safe, and better do it sooner than later if we are to
rework copying code. Also, previous commit shows this *is* useful to
catch some mistakes.
- Add blentranslation `BLT_*` module.
- moved & split `BLF_translation.h` into (`BLT_translation.h`, `BLT_lang.h`).
- moved `BLF_*_unifont` functions from `blf_translation.c` to new source file `blf_font_i18n.c`.
