| Age | Commit message (Collapse) | Author |
|---|
|
The goal is to improve clarity and readability, without
introducing big design changes.
Follows the recent obmat to object_to_world refactor: the
similar naming is used, and it is a run-time only rename,
meaning, there is no affect on .blend files.
This patch does not touch the redundant inversions. Those
can be removed in almost (if not all) cases, but it would
be the best to do it as a separate change.
Differential Revision: https://developer.blender.org/D16367
|
|
Motivation is to disambiguate on the naming level what the matrix
actually means. It is very easy to understand the meaning backwards,
especially since in Python the name goes the opposite way (it is
called `world_matrix` in the Python API).
It is important to disambiguate the naming without making developers
to look into the comment in the header file (which is also not super
clear either). Additionally, more clear naming facilitates the unit
verification (or, in this case, space validation) when reading an
expression.
This patch calls the matrix `object_to_world` which makes it clear
from the local code what is it exactly going on. This is only done
on DNA level, and a lot of local variables still follow the old
naming.
A DNA rename is setup in a way that there is no change on the file
level, so there should be no regressions at all.
The possibility is to add `_matrix` or `_mat` suffix to the name
to make it explicit that it is a matrix. Although, not sure if it
really helps the readability, or is it something redundant.
Differential Revision: https://developer.blender.org/D16328
|
|
This also simplifies using function style casts when moving to C++.
|
|
|
|
|
|
Use `verts` instead of `vertices` and `polys` instead of `polygons`
in the API added in 05952aa94d33eeb50. This aligns better with
existing naming where the shorter names are much more common.
|
|
The constraint attempted to access mesh normals on a mesh with
wrapper type ME_WRAPPER_TYPE_BMESH. This commit reverses the if
statements so that If there is an editmesh then we use that as the
source of truth - otherwise use the evaluated mesh.
Differential Revision: https://developer.blender.org/D15809
|
|
For copy-on-write, we want to share attribute arrays between meshes
where possible. Mutable pointers like `Mesh.mvert` make that difficult
by making ownership vague. They also make code more complex by adding
redundancy.
The simplest solution is just removing them and retrieving layers from
`CustomData` as needed. Similar changes have already been applied to
curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of
the pointers generally makes code more obvious and more reusable.
Mesh data is now accessed with a C++ API (`Mesh::edges()` or
`Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`).
The CoW changes this commit makes possible are described in T95845
and T95842, and started in D14139 and D14140. The change also simplifies
the ongoing mesh struct-of-array refactors from T95965.
**RNA/Python Access Performance**
Theoretically, accessing mesh elements with the RNA API may become
slower, since the layer needs to be found on every random access.
However, overhead is already high enough that this doesn't make a
noticible differenc, and performance is actually improved in some
cases. Random access can be up to 10% faster, but other situations
might be a bit slower. Generally using `foreach_get/set` are the best
way to improve performance. See the differential revision for more
discussion about Python performance.
Cycles has been updated to use raw pointers and the internal Blender
mesh types, mostly because there is no sense in having this overhead
when it's already compiled with Blender. In my tests this roughly
halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million
face grid).
Differential Revision: https://developer.blender.org/D15488
|
|
|
|
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
|
|
Contributed by luzpaz.
Differential Revision: https://developer.blender.org/D14203
|
|
|
|
A simple mistake with a null mesh in rBcfa53e0fbeed.
|
|
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
|
|
|
|
Contributed by luzpaz.
Differential Revision: https://developer.blender.org/D13264
|
|
All constraints were 'made local', including the ones comming from the
reference linked object.
|
|
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
|
|
This shows the text as part of the assertion message.
|
|
Also use doxy style function reference `#` prefix chars when
referencing identifiers.
|
|
Also resolve a warning from the previous commit. The next blocker to
using const is `BKE_mesh_wrapper_ensure_mdata`.
|
|
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.
|
|
The old code only clamped cyclic curves
|
|
|
|
|
