* Remove `DEG_get_evaluated_object` in favor of `DEG_get_evaluated`.
* Remove `DEG_is_original_object` in favor of `DEG_is_original`.
* Remove `DEG_is_evaluated_object` in favor of `DEG_is_evaluated`.
Pull Request: https://projects.blender.org/blender/blender/pulls/138317
Restriction of the nodes api to clearly define never-null function arguments.
Side effects: some assertions and null-check (with early return) were removed.
On the caller side is ensured to never derefer null to pass argument (mainly in RNA).
In addition, one pointer argument now actually a return type.
By-reference return types instead of pointers going to be separate kind of
change since also imply of cleaning up variables created from reference.
Also good future improvement would be to mark a copy-constructor as
explicit for DNA node types.
Pull Request: https://projects.blender.org/blender/blender/pulls/134627
Exposed by bc0b86797c
(but even before we had Asserts in a debug build -- also crashed
WITH_ASSERT_ABORT OFF)
The call to ensure Mesh data from a mesh in edit mode needs
to happen before the triangulation which uses Mesh. This gets rid of
the crash and also previous asserts.
Pull Request: https://projects.blender.org/blender/blender/pulls/133859
The new description for `bNode.type_legacy`:
```
/**
* Legacy integer type for nodes. It does not uniquely identify a node type, only the `idname`
* does that. For example, all custom nodes use #NODE_CUSTOM but do have different idnames.
* This is mainly kept for compatibility reasons.
*
* Currently, this type is also used in many parts of Blender, but that should slowly be phased
* out by either relying on idnames, accessor methods like `node.is_reroute()`.
*
* A main benefit of this integer type over using idnames currently is that integer comparison is
* much cheaper than string comparison, especially if many idnames have the same prefix (e.g.
* "GeometryNode"). Eventually, we could introduce cheap-to-compare runtime identifier for node
* types. That could mean e.g. using `ustring` for idnames (where string comparison is just
* pointer comparison), or using a run-time generated integer that is automatically assigned when
* node types are registered.
*/
```
Pull Request: https://projects.blender.org/blender/blender/pulls/132858
Currently each node's position is stored in the coordinate space of
its parent. To find the location of a node on the canvas, we have to
apply the translation of each of its parents. Also, nodes have hidden
"offset" values used while transforming frame nodes. Together,
those made the system much more complicated than necessary,
and they made the Python API ineffective.
This commit removes usage of the offset values and moves nodes
to be stored in the "global" space of the node canvas. It also resolves
some weird behavior when resizing frame nodes, and fixes a few bugs.
The change is forward compatible, so we still write files with nodes in
the old parent-space format. In 5.0 the conversion when writing can be
removed. The existing Python API also stays the same. A new
"location_absolute" property gives node locations in global space,
and changing the old property also moves the child nodes of frames.
Resolves#92458, #72904.
Pull Request: https://projects.blender.org/blender/blender/pulls/131335
The collada export code was directly using `action->curves` in its
export code, which doesn't work with slotted actions. This commit
updates that code to use wrapper functions that provide access to the
correct fcurves regardless of whether the action is slotted or not.
Note that the import code has not yet been updated, and is left for
a future PR.
Ref: #123424
Pull Request: https://projects.blender.org/blender/blender/pulls/128061
Because we're moving to layered actions, which don't store their
fcurves in a list base, we need to update the places that assume the old
listbase-based structure.
This commit addresses the low-hanging fruit where code was previously
using the `LISTBASE_FOREACH` macro on a listbase of fcurves and it was
fairly obvious how to correctly update the code with minimal changes.
Other cases that either weren't immediately obvious or required
non-trivial code changes (or both) have been left for future PRs.
Additionally, uses of the list base that didn't use `LISTBASE_FOREACH`
were not investigated as part of this PR, whether trivial to update or
not.
Ref: #123424
Pull Request: https://projects.blender.org/blender/blender/pulls/127920
Use snake style naming for all the kernel nodes functions.
Omit kernel prefix in the names since of the using namespace.
Use full forms of the terms
('iter' -> 'iterator', 'ntree' -> 'node_tree', 'rem' -> 'remove', ...).
Pull Request: https://projects.blender.org/blender/blender/pulls/126416
Move all header file into namespace.
Unnecessary namespaces was removed from implementations file.
Part of forward declarations in header was moved in the top part
of file just to do not have a lot of separate namespaces.
Pull Request: https://projects.blender.org/blender/blender/pulls/121637
Move the public functions from the editors/object (`ED_object.hh`)
header to the `blender::ed::object` namespace, and move all of the
implementation files to the namespace too. This provides better code
completion, makes it easier to use other C++ code, removes unnecessary
redundancy and verbosity from local uses of public functions, and more
cleanly separates different modules.
See the diff in `ED_object.hh` for the main renaming changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/119947
There are still a few places that are more complicated where the replacement
to `IDP_New` isn't obvious, but this commit replaces most uses of the ugly
`IDPropertyTemplate` usage.
The `object_to_world` and `world_to_object` matrices are set during
depsgraph evaluation, calculated from the object's animated location,
rotation, scale, parenting, and constraints. It's confusing and
unnecessary to store them with the original data in DNA.
This commit moves them to `ObjectRuntime` and moves the matrices to
use the C++ `float4x4` type, giving the potential for simplified code
using the C++ abstractions. The matrices are accessible with functions
on `Object` directly since they are used so commonly. Though for write
access, directly using the runtime struct is necessary.
The inverse `world_to_object` matrix is often calculated before it's
used, even though it's calculated as part of depsgraph evaluation.
Long term we might not want to store this in `ObjectRuntime` at all,
and just calculate it on demand. Or at least we should remove the
redundant calculations. That should be done separately though.
Pull Request: https://projects.blender.org/blender/blender/pulls/118210
Bone collection visibility now respects their hierarchy.
A bone collection is only visible when it is marked as visible and all
its ancestors (so parents, greatparents, etc.) are visible. Root bone
collections have no ancestors by definition, and only consider their own
visibility.
The effective ancestors' visibility is stored on each bone collection,
in its `BONE_COLLECTION_ANCESTORS_VISIBLE` flag. This makes it possible
to determine the effective visibility from just the flags of the bone
collection itself.
The `BONE_COLLECTION_ANCESTORS_VISIBLE` flag is now stored, with the
other flags, in `BoneCollection::flags`. This means that it's stored in
DNA, even though it's derived data and should actually be stored in a
runtime struct. However, `BoneCollection` doesn't have any runtime
struct yet, and I don't feel that the introduction of this flag is a
good enough reason to introduce that just yet.
Pull Request: https://projects.blender.org/blender/blender/pulls/116784
"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.
Move the contents of `ANIM_bone_collections.h` into its C++
`ANIM_bone_collections.hh` sibling. Blender is C++ by now that we can do
without the C header.
No functional changes.
If the DAE file was written with something other than Blender 4.0, it
doesn't have the bone collections info. That resulted in a nullptr, which
is now handled properly.
Replace the import/export of armature layers with bone collections.
The Old Way:
- Export: Each bone would store which armature layer it was on.
- Import: All armature layers that contain at least a bone are shown.
The New Way:
- Export: Each armature contains a list of its bone collections,
including which one is active and which ones are visible.
- Export: Each bone stores which bone collection it is on.
- Import: the above data is simply used as-is.
Due to limitations of the current Collada importer code, each "extra"
tag can only occur once per Collada node. This means that it was
impossible to write a `<collection name="Bones">` tag for each bone
collection, as only one of those would actually be stored by the
importer for further processing. To work around this limitation, all
bone collection related tags store their values as newline-separated
strings. Example:
```
<node id="Armature">
<extra>
<technique profile="blender">
<collections sid="collections" type="string">Layer 1
Layer 3b
Group
That One Bone</collections>
<visible_collections sid="visible_collections" type="string">Layer 1
Layer 3b
That One Bone</visible_collections>
<active_collection sid="active_collection" type="string">That One Bone</active_collection>
</technique>
</extra>
</node>
```
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
