The newly added "tangent_pair" calculation functions meant the names
didn't read well in some cases, use this style of naming for clarity:
- BM_face_calc_tangent_from_*
- BM_face_calc_tangent_pair_from_*
When using clangd or running clang-tidy on headers there are
currently many errors. These are noisy in IDEs, make auto fixes
impossible, and break features like code completion, refactoring
and navigation.
This makes source/blender headers work by themselves, which is
generally the goal anyway. But #includes and forward declarations
were often incomplete.
* Add #includes and forward declarations
* Add IWYU pragma: export in a few places
* Remove some unused #includes (but there are many more)
* Tweak ShaderCreateInfo macros to work better with clangd
Some types of headers still have errors, these could be fixed or
worked around with more investigation. Mostly preprocessor
template headers like NOD_static_types.h.
Note that that disabling WITH_UNITY_BUILD is required for clangd to
work properly, otherwise compile_commands.json does not contain
the information for the relevant source files.
For more details see the developer docs:
https://developer.blender.org/docs/handbook/tooling/clangd/
Pull Request: https://projects.blender.org/blender/blender/pulls/132608
Replace plain-text type information with the type syntax used
for Python's type annotations as it's more concise, especially for
callbacks which often didn't include useful type information.
Note that this change only applies to inline doc-strings,
generated doc-strings from RNA need to be updated separately.
Details:
- Many minor corrections were made when "list" was incorrectly used
instead of "sequence".
- Some type information wasn't defined in the doc-strings and has been
added.
- Verbose type info would benefit from support for type aliases.
- `_PySet_NextEntry` has been removed, use generic iterator access
which will has some additional overhead as it needs to create
an iterator to access the values.
- Add v3.13 compatibility defines to account for renaming:
_PyObject_LookupAttr -> PyObject_GetOptionalAttr
_PyLong_AsInt -> PyLong_AsInt
- Unfortunately use of Python's internal API needs to be used to
inspect op-codes in `bpy_driver.cc`.
Testing GLTF/FBX IO there isn't any significant performance impact
from these changes.
Resolves#123871.
This replaces the older dynamic c array macros with blender::Vector in
bmesh_polygon_edgenet. This is the only remaining use of the old array
machinery and removal of `BLI_array.h / .c` can happen immediately
afterwards.
See #103343
Pull Request: https://projects.blender.org/blender/blender/pulls/119975
Previously, values for `ID.flag` and `ID.tag` used the prefixes `LIB_` and
`LIB_TAG` respectively. This was somewhat confusing because it's not really
related to libraries in general. This patch changes the prefix to `ID_FLAG_` and
`ID_TAG_`. This makes it more obvious what they correspond to, simplifying code.
Pull Request: https://projects.blender.org/blender/blender/pulls/125811
`BMVert.copy_from_vert_interp()`'s description and the name `vert_pair`
implies two verts, but the argument itself was described and typed as a
single `BMVert`.
Ref: !122974
The type for `bpy_struct.keyframe_insert()`'s `options` parameter was
instead applied to a non-existent `flag` parameter.
The description and type for `mathutils.Vector.Repeat()`'s `vector`
parameter was instead applied to a non-existent `tuple` parameter.
Also fix a reference to `BMElemeSeq` instead of `BMElemSeq`.
Ref: !122734
- `BMLayerItem.copy_from(other)` had a typo in its docstring that prevented `other` being typed.
- `BMesh.from_object()` and `BMesh.from_mesh()` had untyped arguments.
- `BMVert.copy_from_vert_interp()`'s `fac` argument was untyped.
- `remove(item)` method of `BMVertSeq`, `BMEdgeSeq` and `BMFaceSeq` had no type for `item`.
- `get()` method of `BMEdgeSeq` and `BMFaceSeq` had "sequence" in the description of `verts` but not in the type.
Pull Request: https://projects.blender.org/blender/blender/pulls/122374
Make the naming consistent with the recent change from "loop" to
"corner". Avoid the need for a special type for these triangles by
conveying the semantics in the naming instead.
- `looptris` -> `corner_tris`
- `lt` -> `tri` (or `corner_tri` when there is less context)
- `looptri_index` -> `tri_index` (or `corner_tri_index`)
- `lt->tri[0]` -> `tri[0]`
- `Span<MLoopTri>` -> `Span<int3>`
- `looptri_faces` -> `tri_faces` (or `corner_tri_faces`)
If we followed the naming pattern of "corner_verts" and "edge_verts"
exactly, we'd probably use "tri_corners" instead. But that sounds much
worse and less intuitive to me.
I've found that by using standard vector types for this sort of data,
the commonalities with other areas become much clearer, and code ends
up being naturally more data oriented. Besides that, the consistency
is nice, and we get to mostly remove use of `DNA_meshdata_types.h`.
Pull Request: https://projects.blender.org/blender/blender/pulls/116238
The version of BM_elem_attrs_copy that took a map used a reference
the version without a map didn't, which is fairly confusing.
Pass by pointer now unless this is part of a wider refactor
to move to references everywhere.
Continuation of fix for #115776. Removes attribute copy functions
that calculate the map inline, this is error prone as it's easy to
call these functions from a loop which may result in poor performance.
Fixes#115776
Create a minimal structure that contains the instructions necessary to
copy from one custom data format to another. This structure is similar
to the one used in dfacaf4f40. It should have been used in
9175d9b7c2, which instead introduced quadratic performance
relative to the number of layers when copying every element.
In this commit, copying the entire mesh and adding new custom data
are explicitly changed to use the new map to speed up copying many
elements at a time.
The non-map attribute copy functions are also changed to check for when
the source and result BMeshes are the same. In that case it's much
faster to call the "same format" function from 9175d9b7c2.
For numbers, the timings are arbitrarily influenced by how many layers
I add in my testing. With 50 or so layers, a 10x difference is easily
observable though.
Pull Request: https://projects.blender.org/blender/blender/pulls/115824
"mesh" reads much better than "me" since "me" is a different word.
There's no reason to avoid using two more characters here. Replacing
all of these at once is better than encountering it repeatedly and
doing the same change bit by bit.
Store paint masks as generic float attributes, with the name
`".sculpt_mask"`. This is similar to 060a534141, which made
the same change for face sets. The benefits are general
consistency, nicer code, and more support in newer areas
that deal with attributes like geometry nodes.
The RNA API is replaced with one created in Python. The new
API only presents a single layer as an attribute class, so it
should be simpler to use in general:
- Before: `object.data.vertex_paint_masks[0].data[0].value`
- After: `object.data.vertex_paint_mask.data[0].value`
Pull Request: https://projects.blender.org/blender/blender/pulls/115119
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.
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
