This is the same principle as D15418 and D15532, but this time it's
only really needed for "IK".
Nevertheless it's probably good to add them anyway in case they get
renamed and don't share a translation with other messages somewhere
else in the code, for instance if it is decided that new constraint names
shouldn’t include spaces, like other data do.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D15571
- The custom space target never needs B-Bone data (used by depsgraph).
- When drawing the relationship lines use the space matrix directly.
- Don't use the custom target to control the target space type dropdown.
Differential Revision: https://developer.blender.org/D9732
Add calls to a few locations that look like they may need to
initialize the Custom Space matrix, i.e. generally any place
that computes target matrices.
Differential Revision: https://developer.blender.org/D9732
Rename and simplify the function for initializing the custom space,
avoiding the need for the calling code to be aware of the internals
of bConstraintOb. This patch should not change any behavior.
This was split off from D9732.
Differential Revision: https://developer.blender.org/D15252
Since the custom target is a feature implemented at constraint
level, it is more appropriate to handle it in the common wrapper
functions, instead of modifying all the type specific callbacks
like get_constraint_targets and flush_constraint_targets.
Also, tag the special target with a flag so other code can
handle it appropriately where necessary.
This was split from D9732, and effectively reverts and refactors
part of D7437. This patch should cause no functional changes.
Differential Revision: https://developer.blender.org/D15168
Instead of directly accessing constraint-specific callbacks
in code all over blender, introduce two wrappers to retrieve
and free the target list.
This incidentally revealed a place within the Collada exporter
in BCAnimationSampler.cpp that didn't clean up after retrieving
the targets, resulting in a small memory leak. Fixing this should
be the only functional change in this commit.
This was split off from D9732.
Differential Revision: https://developer.blender.org/D13844
The "dir" argument to `BKE_where_on_path` was only actually
used in a few places. It's easier to see where those are if there
isn't always a dummy argument.
- Missing star prefix.
- Unnecessary indentation.
- Blank line after dot-points
(otherwise doxygen merges with the previous dot-point).
- Use back-slash for doxygen commands.
- Correct spelling.
Both the Alembic and USD libraries use double precision floating
point numbers internally to store time. However the Alembic I/O
code defaulted to floats even though Blender's Scene FPS, which is
generally used for look ups, is stored using a double type. Such
downcasts could lead to imprecise lookups, and would cause
compilation warnings (at least on MSVC).
This modifies the Alembic exporter and importer to make use of
doubles for the current scene time, and only downcasting to float
at the very last steps (e.g. for vertex interpolation). For the
importer, doubles are also used for computing interpolation weights,
as it is based on a time offset.
Although the USD code already used doubles internally, floats were used
at the C API level. Those were replaced as well.
Differential Revision: https://developer.blender.org/D13855
The Alembic procedural was only enabled during viewport renders
originally because it did not have any caching strategy. Now that
is does, we can allow its usage in final renders.
This also removes the `dag_eval_mode` argument passing to
`ModifierTypeInfo.dependsOnTime` which was originally added to detect if
we are doing a viewport render for enabling the procedural.
Differential Revision: https://developer.blender.org/D14520
This commit renames enums related the "Curve" object type and ID type
to add `_LEGACY` to the end. The idea is to make our aspirations clearer
in the code and to avoid ambiguities between `CURVE` and `CURVES`.
Ref T95355
To summarize for the record, the plans are:
- In the short/medium term, replace the `Curve` object data type with
`Curves`
- In the longer term (no immediate plans), use a proper data block for
3D text and surfaces.
Differential Revision: https://developer.blender.org/D14114
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
Part of T91671.
Not much else to say, this is mainly a massive deletion of code.
Note that a few cleanups possible after this proxy removal were kept out
of this commit to try to reduce a bit its size.
Reviewed By: sergey, brecht
Maniphest Tasks: T91671
Differential Revision: https://developer.blender.org/D13995
As described in T91186, this commit moves mesh vertex normals into a
contiguous array of float vectors in a custom data layer, how face
normals are currently stored.
The main interface is documented in `BKE_mesh.h`. Vertex and face
normals are now calculated on-demand and cached, retrieved with an
"ensure" function. Since the logical state of a mesh is now "has
normals when necessary", they can be retrieved from a `const` mesh.
The goal is to use on-demand calculation for all derived data, but
leave room for eager calculation for performance purposes (modifier
evaluation is threaded, but viewport data generation is not).
**Benefits**
This moves us closer to a SoA approach rather than the current AoS
paradigm. Accessing a contiguous `float3` is much more efficient than
retrieving data from a larger struct. The memory requirements for
accessing only normals or vertex locations are smaller, and at the
cost of more memory usage for just normals, they now don't have to
be converted between float and short, which also simplifies code
In the future, the remaining items can be removed from `MVert`,
leaving only `float3`, which has similar benefits (see T93602).
Removing the combination of derived and original data makes it
conceptually simpler to only calculate normals when necessary.
This is especially important now that we have more opportunities
for temporary meshes in geometry nodes.
**Performance**
In addition to the theoretical future performance improvements by
making `MVert == float3`, I've done some basic performance testing
on this patch directly. The data is fairly rough, but it gives an idea
about where things stand generally.
- Mesh line primitive 4m Verts: 1.16x faster (36 -> 31 ms),
showing that accessing just `MVert` is now more efficient.
- Spring Splash Screen: 1.03-1.06 -> 1.06-1.11 FPS, a very slight
change that at least shows there is no regression.
- Sprite Fright Snail Smoosh: 3.30-3.40 -> 3.42-3.50 FPS, a small
but observable speedup.
- Set Position Node with Scaled Normal: 1.36x faster (53 -> 39 ms),
shows that using normals in geometry nodes is faster.
- Normal Calculation 1.6m Vert Cube: 1.19x faster (25 -> 21 ms),
shows that calculating normals is slightly faster now.
- File Size of 1.6m Vert Cube: 1.03x smaller (214.7 -> 208.4 MB),
Normals are not saved in files, which can help with large meshes.
As for memory usage, it may be slightly more in some cases, but
I didn't observe any difference in the production files I tested.
**Tests**
Some modifiers and cycles test results need to be updated with this
commit, for two reasons:
- The subdivision surface modifier is not responsible for calculating
normals anymore. In master, the modifier creates different normals
than the result of the `Mesh` normal calculation, so this is a bug
fix.
- There are small differences in the results of some modifiers that
use normals because they are not converted to and from `short`
anymore.
**Future improvements**
- Remove `ModifierTypeInfo::dependsOnNormals`. Code in each modifier
already retrieves normals if they are needed anyway.
- Copy normals as part of a better CoW system for attributes.
- Make more areas use lazy instead of eager normal calculation.
- Remove `BKE_mesh_normals_tag_dirty` in more places since that is
now the default state of a new mesh.
- Possibly apply a similar change to derived face corner normals.
Differential Revision: https://developer.blender.org/D12770
rBd6891d9bee2b introduced a way to apply a single constraint from the
constraint stack. For this we want to work in the evaluated domain, in
particular the constraint target should be evaluated (the shrinkwrap
constraint needs to have access to the target's evaluated mesh).
Thx a lot to @sergey for handholding here!
Maniphest Tasks: T94600
Differential Revision: https://developer.blender.org/D13765
- 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
As also explained in D6134, in most case of Stretch To usage in
rigs, it is desirable to use swing rotation, either via the old
method of pairing the constraint with Damped Track, or via the
Swing rotation type introduced in 2.82. This is for instance true
for all usages of the constraint in Rigify.
The reason can be understood by realizing that unlike order-
dependent euler rotations, swing is not biased to an axis, and
isn't affected by gimbal lock effects at merely 90 degrees
of rotation (it has only one singularity at 180 degrees).
Thus it makes sense to change the default for newly created
constraints to the Swing mode. This has no backward compatibility
concerns except for old tutorials and rig generation scripts.
Differential Revision: https://developer.blender.org/D12643
This patch exposes the Cycles Alembic Procedural through the MeshSequenceCache
modifier in order to use and test it from Blender.
To enable it, one has to switch the render feature set to experimental and
activate the Procedural in the modifier. An Alembic Procedural is then
created for each CacheFile from Blender set to use the Procedural, and each
Blender object having a MeshSequenceCache modifier is added to list of objects
of the right procedural.
The procedural's parameters derive from the CacheFile's properties which are
already exposed in the UI through the modifier, although more Cycles specific
options might be added in the future.
As there is currently no cache controls and since we load all the data at the
beginning of the render session, the procedural is only available during
viewport renders at the moment. When an Alembic procedural is rendered, data
from the archive are not read on the Blender side.
If a Cycles render is not active and the CacheFile is set to use the Cycles Procedural,
bounding boxes are used to display the objects in the scene as a signal that the
objects are not processed by Blender anymore. This is standard in other DCCs.
However this does not reduce the memory usage from Blender as the Alembic data
was already loaded either during an import or during a .blend file read.
This is mostly a hack to test the Cycles Alembic procedural until we have a
better Blender side mechanism for letting renderers load their own geometry,
which will be based on import and export settings on Collections (T68933).
Ref T79174, D3089
Reviewed By: brecht, sybren
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D10197
Add Apply Constraint, Duplicate Constraint, and Copy To Selected
operators, and include them in a menu similar to the menu for modifiers.
The shortcuts in the extras menu are also matched to modifiers.
All the here added operators are intended to work exactly like the
analogous ones for modifiers. That means the apply operator should apply
a constraint as if it was first in the list, just like modifiers do. I
have added the same warning message as for modifiers when that happens.
The decision to use this approach of appling the constraint as if it was
first, was made for consistency with modifiers. People are already used
to how it works there. Is also provides more intricate control over the
applied transforms, then just applying all constraints up to that one.
Apply all constraints is already kinda implemented in Bake Animation.
Reviewed By: HooglyBoogly, sybren, #user_interface
Differential Revision: https://developer.blender.org/D10914
Practice shows that when combining actions and direct animation
it is usually best to combine location, rotation and scale
separately, which is implemented by the Split Channels modes
recently introduced in D9469 for Copy Transforms. This completes
the same set of 6 choices for the Action Constraint.
The default for new constraints is changed to the newly
added Before Original (Split Channels) mode.
The original patch is motivated by Loic Pinsard, who created
an addon that does the equivalent of this feature by splitting
the action into two, separating location and rotation+scale.
Differential Revision: https://developer.blender.org/D7547
Code freeing the array would not properly reset its length value to
zero.
Note that this corrupted data could also be saved in .blend files, so
had to bump fileversion and add some doversion code too.
Fix T90166: crash when creating a liboverride.
This is an initial implementation of a USD importer.
This work is comprised of Tangent Animation's open source USD importer,
combined with features @makowalski had implemented.
The design is very similar to the approach taken in the Alembic
importer. The core functionality resides in a collection of "reader"
classes, each of which is responsible for converting an instance of a
USD prim to the corresponding Blender Object representation.
The flow of control for the conversion can be followed in the
`import_startjob()` and `import_endjob()` functions in `usd_capi.cc`.
The `USDStageReader` class is responsible for traversing the USD stage
and instantiating the appropriate readers.
Reviewed By: sybren, HooglyBoogly
Differential Revision: https://developer.blender.org/D10700
Add a new transformation space choice for bone constraints, which
represent the local transformation of the target bone in the constraint
owner's local space.
The use case for this is transferring the local (i.e. excluding the
effect of parents) motion of one bone to another one, while ignoring
the difference between their rest pose orientations.
The new option replaces the following setup:
* A `child` bone of the `target`, rotated the same as `owner` in rest pose.
* A `sibling` bone of the `target`, positioned same as `child` in rest
pose and using Copy Transforms in World Space from `child`.
* The `owner` bone constraint uses Local Space of `sibling`.
(This analogy applies provided both bones use Local Location)
Differential Revision: https://developer.blender.org/D9493
This constraint can be naturally viewed as a prototype for a future
4x4 matrix math node (or subset thereof), since its basic semantics
already is matrix assignment. Thus it makes sense to add math options
to this constraint to increase flexibility in the meantime.
This patch adds support for several operations that would be useful:
- An option to remove shear in the incoming target matrix.
Shear is known to cause issues for various mathematical operations,
so an option to remove it at key points is useful.
Constraints based on Euler like Copy Rotation and Limit Rotation
already have always enabled shear removal built in, because their
math doesn't work correctly with shear.
In the future node system shear removal would be a separate node
(and currently Limit Rotation can be used as a Remove Shear constraint).
However removing shear from the result of the target space conversion
before mixing (similar to Copy Rotation) has to be built into
Copy Transforms itself as an option.
- More ways to combine the target and owner matrices.
Similar to multiple Inherit Scale modes for parenting, there are
multiple ways one may want to combine matrices based on context.
This implements 3 variants for each of the Before/After modes
(one of them already existing).
- Full implements regular matrix multiplication as the most basic
option. The downside is the risk of creating shear.
- Aligned emulates the 'anti-shear' Aligned Inherit Scale mode,
and basically uses Full for location, and Split for rotation/scale.
(This choice already existed.)
- Split Channels combines location, rotation and scale separately.
Looking at D7547 there is demand for Split Channels in some cases,
so I think it makes sense to include it in Copy Transforms too, so that
the Mix menu items can be identical for it and the Action constraint.
Differential Revision: https://developer.blender.org/D9469
Generally the evaluated mesh should not be changed, since that is the
job of the modifier stack. Current code is far from const correct in
that regard. This commit uses a const variable for the reult of
`BKE_object_get_evaluated_mesh` in some cases. The most common
remaining case is retrieving a BVH tree from the mesh.
Add a call to orthogonalize the matrix before processing for the
same reasons as D8915, and an early exit in case no limits are
enabled for a bit of extra efficiency.
Since the constraint goes through Euler decomposition, it would
in fact remove shear even before this change, but the resulting
rotation won't make much sense.
This change allows using the constraint without any enabled limits
purely for the purpose of efficiently removing shear.
Differential Revision: https://developer.blender.org/D9626
Since Limit Rotation is based on Euler decomposition, it should allow
specifying the order to use for the same reasons as Copy Rotation does,
namely, if the bone uses Quaternion rotation for its animation channels,
there is no way to choose the order for the constraint.
Ref D9626
Previously, the "follow path constraint" and "follow parented curve"
were clamped. This restriction was lifted in rBcf2baa585cc8
Add back an option to get the old behavior in the "Path animation" settings.
Reviewed By: Sybren
Differential Revision: http://developer.blender.org/D11263
The term `verify` doesn't fit with what this function does
and is sometimes used to check data is valid or to control validity
checking as with `RNA_define_verify_sdna`.
use more common term `ensure`.
The issue was that where_on_path uses a resampled curve to get the data
from the curve. This leads to disconnects between the curve the user
sees and the evaluated location data.
To fix this we simply use the actual curve data the user can see.
The older code needed a cleanup either way as there were hacks in other
parts of the code trying to work around some brokenness. This is now
fixed and we no longer need to clamp the evaluation range to 0-1 or make
helper functions to make it do what we actually want.
Reviewed By: Campbell, Sybren
Differential Revision: http://developer.blender.org/D10898
The double quaternion blending method in addition to the deformation
matrix of each bone requires their rest matrices. For ordinary bones
this literally should use the bone rest matrix without any ambiguity.
However, it was also using the bone rest matrix for all of its
B-Bone segments, which is incorrect and causes strange deformation
in some cases involving extreme non-uniform scale, especially
at boundaries between different B-Bones. There is also a similar
known issue that happens with scale at bending joints, and this
fix reduces the distortion when both bones are B-Bones.
This changes both the Armature modifier and the Armature constraint
to use the actual segment rest matrices. Unlike bones, these can have
scale even in rest pose, so normalization is required.
Differential Revision: https://developer.blender.org/D10003
