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 code ensuring that an object (or obdata) is not made local if it is
used by linked data that is not tagged to be made local was blatantly
buggy, leading to over-detecting such cases.
Note that this code remains fairly fragile imho, think the whole Main
data-base of IDs should be checked, other data-types than Objects can
use objects! But this is for another day.
When copying (CTRL+L->Animation Data) a driver between two objects
that are linked with library overrides, `AnimData` was not created.
This did crash Blender when it tried to use the `nullptr`
The reason it crashed is because the function
`DEG_id_tag_update()`
was never called.
Fix it by restructuring the code so the function gets called
Pull Request: https://projects.blender.org/blender/blender/pulls/110795
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
The `OBJECT_OT_simulation_nodes_cache_delete` operator
would delete the parent bake directory. This could lead to catastrophic
loss of data if the user set their bake directory to a folder that
contains other files or folders.
This commit makes sure that only the "meta" and "bdata" folders get
deleted in the parent directory.
Pull Request: https://projects.blender.org/blender/blender/pulls/110999
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
This updates the signature of `RNA_def_property_update_runtime`
which previously just has a `const void *` input. This made it difficult
to know what function signature is expected and also does not result
in compile errors when a wrong function is provided.
There is one case which required a different signature, so now there
is a separat function for that case.
Remove the "_for_read" suffix from methods to get geometry and geometry
components. That should be considered the default, so the suffix just
adds unnecessary text. This is consistent with the attribute API and
various implicit sharing data access methods.
Use "from_mesh" instead of "create_with_mesh". This is consistent with
the recently used naming for the `IndexMask` API.
Pull Request: https://projects.blender.org/blender/blender/pulls/110738
The goal is to reuse the same bake items for simulation and normal baking (#110137).
Previously, the bake data was tied to a simulation state which made it harder to reuse.
Now the code for the following things can be reused easily:
- Convert geometry node socket values into bake items and back.
- Serialize and deserialize bake items.
Pull Request: https://projects.blender.org/blender/blender/pulls/110577
Add an API for armature layer access. Instead of accessing `arm->layer`
and friends directly, the code now uses this API. This will make things
easier to replace by bone collections in the future.
The functions are named "bonecoll" (short for "bone collection"), as
that's the soon-to-be-introduced replacement for armature layers. This
API is the first step towards that replacement, and should help to
reduce the changes necessary when functional changes are committed.
This also creates a new module `source/blender/animrig` for Animation &
Rigging code. This will, for example, house the bone collection system
in the near future.
There is a bunch of code currently spread across blenkernel and editors
in a rather ad-hoc way; it is intended that at some point that code gets
moved into `animrig` as well (or at least the subset of that code where
such a move makes sense; brain still required).
Ref: #108941
No functional changes.
Implements the rest of #101689, after 5e9ea9243b.
- `vdata` -> `vert_data`
- `edata` -> `edge_data`
- `pdata` -> `face_data`
- `ldata` -> `loop_data`
A deeper rename of `loop` to `corner` will be proposed as a next
step, and renaming `totvert` and `totedge` can be done separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/110432
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
Implements part of #101689.
The "poly" name was chosen to distinguish the `MLoop` + `MPoly`
combination from the `MFace` struct it replaced. Those two structures
persisted together for a long time, but nowadays `MPoly` is gone, and
`MFace` is only used in some legacy code like the particle system.
To avoid unnecessarily using a different term, increase consistency
with the UI and with BMesh, and generally make code a bit easier to
read, this commit replaces the `poly` term with `poly`. Most variables
that use the term are renamed too. `Mesh.totface` and `Mesh.fdata` now
have a `_legacy` suffix to reduce confusion. In a next step, `pdata`
can be renamed to `face_data` as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/109819
This affected `Mesh Deform`, `Corrective Smooth` and `Laplacian Smooth`.
Exposed by 57ea827bfb (e5ec04d73c).
Evaluating the incoming mesh can be different in
`BKE_object_handle_data_update` as opposed to
`object_force_modifier_update_for_bind` due to different
`CustomData_MeshMasks` being used (the former used a handpicked set, the
later was still using `CD_MASK_BAREMESH`). But since moving many
relevant [to modifiers] data to attributes, this could lead to binding go
wrong (e.g. reporting a vertex count mismatch as reported in #110021
which was due to the fact that creases were not propagated and that
changed the output [also vertex count] of a subdivision modifier in the
stack).
Now use `CD_MASK_DERIVEDMESH` in `object_force_modifier_update_for_bind`
to get all relevant attributes for evaluation (this is not used in `BKE_object_handle_data_update`
to avoid a big performance impact there).
Also fixes#109626 afaict.
Should probably go into 3.6 LTS (maybe even 3.3 LTS).
Pull Request: https://projects.blender.org/blender/blender/pulls/110095
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`.
Make it harder to retrieve a mutable attribute from const a const mesh,
and use the attribute search function to check multiple domains and
colors at once.
