This adds a "Solver" option to the geo boolean node, with the options
Exact and Float.
The current geo boolean node only uses the Exact solver.
This adds the ability to use the faster original floating point boolean solver.
The float solver has issues with coplanar and other coincident geometry,
but is generally much faster than the Exact solver, and users have asked
for this option (which is available in the Boolean Modifier and edit mode
boolean tool).
Like the modifier, the Float solver needs to convert the Mesh to BMesh,
do the operation, and then convert back to Mesh. It also has to do it
iteratively if more than two operands are supplied.
This is the first of a planned series of commits that will add a
new exact boolean solver, based on the Ember paper, as a solver option.
Ember will be much faster than the current exact solver, but may still not
be as fast as float, and also will not handle some non-volume-enclosing
inputs as well as Float, so it is likely that the Float solver will always remain.
We may eventually retire the old Exact Solver, however.
This commit also prepares for more sensible code in the future by
changing the internal enum names for the solvers to better reflect the
algorithms used: Fast -> Float, and Exact -> Mesh_Arr (which means
"Mesh Arrangments, the name of the paper upon which the current
exact solver is based).
Co-authored-by: Howard Trickey <trickey@google.com>
Co-authored-by: Hans Goudey <hans@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/119294
"Own" (the adjective) cannot be used on its own. It should be combined
with something like "its own", "our own", "her own", or "the object's own".
It also isn't used separately to mean something like "separate".
Also, "its own" is correct instead of "it's own" which is a misues of the verb.
Armature deformation modifier for Grease Pencil v3.
Changes compared to GPv2:
- `multi` DNA field was unused and was removed.
- `vert_coords_prev` array is unused and was removed (gets passed to
armature functions but never gets allocated).
- GPv3 modifier uses the common `influence` struct to store the vertex
group name, for consistency. The
`GREASE_PENCIL_INFLUENCE_INVERT_VERTEX_GROUP` flag is copied to
`deformflag` as `ARM_DEF_INVERT_VGROUP` before evaluation, which is
used internally by armature functions.
- `BKE_armature_deform_coords_with_curves` is added as another variant
of the deform function, but uses C++ parameter types (spans instead
of raw pointers). It gets a `Span<MDeformVert>` directly instead of
deducing it internally from the object type. This is because we want
to do this curve-by-curve and already use arbitrary vector spans for
positions.
Pull Request: https://projects.blender.org/blender/blender/pulls/118752
This is a migration of the current Line Art modifier to GPv3.
Note:
- The modifier is using the exact same DNA structure as the old one, it's re-defined in a different name. At the moment all the variable names and placement after the `ModifierData` part should stay exactly the same until we do proper versioning of the modifier data and completely remove the GPv2 support.
- Vertex weight transfer feature no longer supports name initial matching ("group" used to match "group1","group2" etc). Now it will only transfer vertex weight from source vertex groups that has the exact same name as specified.
Pull Request: https://projects.blender.org/blender/blender/pulls/117028
When deleting all the segments the active index is generally 0. Adding a
new segment increments the active index, which pushes it out of range.
The code should not expect active index to be inside the current range.
Pull Request: https://projects.blender.org/blender/blender/pulls/118143
Ported lattice modifier from GPv2.
The `LatticeDeformData` is no longer stored in the modifier data, but calculated on-the-fly like in the mesh deform modifier. This is quite trivial data and only stores deformed positions of the lattice, so not really worth the effort and complexity of caching it.
Pull Request: https://projects.blender.org/blender/blender/pulls/117955
Thickness modifier ported to Grease Pencil v3.
Note: Uniform thickness range and UI step changed to better
match new thickness of blender unit.
![image](/attachments/2e9c9bfa-d869-4bec-a529-c3833390a201)
Pull Request: https://projects.blender.org/blender/blender/pulls/117631
Smooth modifier ported to Grease Pencil 3.0
Exposed `smooth_curve_attribute()` from `grease_pencil_edit.cc`
to achieve the smoothing effect. It will not be the exact same result
as the old algorithm.
Pull Request: https://projects.blender.org/blender/blender/pulls/116975
Opacity modifier implementation based on GP2.
Functionality is largely unchanged.
_Color Mode_ is either `Stroke` or `Fill` for modifying color opacity or
`Hardness`.
_Uniform Opacity_ does two things at once (!):
- Sets the same opacity value for every point in a stroke.
- Sets opacity as an absolute value rather than a factor.
_Weight as Factor_ (button to the right of Opacity Factor): Use the
vertex group as opacity __factor__ rather than an overall __influence__.
This is confusing and hard to convey, but copies behavior from GP2.
The _Influence_ panel contains the same filter settings as the GP2
modifier, with some small changes:
- _Layer_ selects only strokes in the respective layer (with an _Invert_
option)
- _Material_ selects only points with the respective material (with an
_Invert_ option)
- _Layer Pass_ and _Material Pass_ select only strokes/points which are
rendered in the respective pass.
_Note 1: Layers don't have UI for setting a pass yet, this will be a
generic layer attribute. This can be set through the API for testing._
_Note 2: In GP2 a pass value of zero was used to disable pass filters.
Since zero is a valid pass ID an explicit flag has been added for the
purpose of turning pass filters on and off._
- _Vertex Group_: This can be used as an additional influence filter on
points. If _Weight as Factor_ is enable the vertex group instead
replaces the opacity factor. In _Fill_ mode the vertex group weight of
the stroke's first point is used as influence for the entire stroke.
- _Custom Curve_ is another possible influence factor per point. The
curve input value is the relative position of a point along its
stroke.
The Influence settings have been moved into a separate DNA struct, which
should help with reusability in various modifiers. Various utility
functions can be found int `MOD_grease_pencil_util.hh` for handling
influence settings and generating `IndexMasks` for modernized C++ code.
Pull Request: https://projects.blender.org/blender/blender/pulls/116946
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.
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
Using run-time members in the surface modifier complicated code-review
and caused an unnecessary renaming in `dna_rename_defs.h`.
Also rename:
- `x` -> `vert_positions_prev`.
- `v` -> `vert_velocities`.
- `cfra` -> `cfra_prev`.
A studio request actually.
The goal is to cover rather typical situation: when the mesh was
bound to target when the target was on subdivision level 0 but
uses a higher subdivision level for rendering. Example of such
setup is a facial hair bound to the face.
The idea of this change is to use first N vertices from the target
where N is the number of vertices on target during binding process.
While this sounds a bit arbitrary it covers typical modifier setup
used for rigging. Arguably, it is not more arbitrary than using a
number of polygons (which is how the modifier was checking for
changes on target before this change).
Quite straightforward change. A bit tricky part was to not break
the behavior since before this change we did not track number of
vertices sued when binding. The naming I'm also not super happy
with and just followed the existing one. Ideally the variables in
DNA will be prefixed with `target_` but doing it for an existing
field would mean compatibility change, and only using prefix for
the new field will introduce weird semantic where the polygons
count will be even more easily confused with a count on the
deforming mesh.
Differential Revision: https://developer.blender.org/D14830
Make it explicit that counter is about target mesh.
Use DNA rename for it so that the files stay compatible.
Also renamed some purely runtime fields to replace `t`
prefix with `target` as the short `t` is super easy
to miss.
Differential Revision: https://developer.blender.org/D14835
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
The mirror modifiers merge option caused unnecessary re-ordering
to the vertex array with original vertices merging into their copies.
While this wasn't an error, it meant creating a 1:1 mapping from input
vertices to their final output wasn't reliable (when looping over
vertices first to last) as is done in
BKE_editmesh_vert_coords_when_deformed.
As merging in either direction is supported, keep the source meshes
vertices in-order since it allows the vertex coordinates to be extracted.
NOTE: Since this change introduce issues for some cases (e.g. bound
modifiers like SurfaceDeform), this change is only applied to newly
created modifiers, existing ones will still use the old incorrect merge
behavior.
Reviewed By: @brecht
Maniphest Tasks: T93321, T91444
Differential Revision: https://developer.blender.org/D13355
Previously fluid simulation and Alembic modifiers had a dedicated function
to query the velocity for motion blur. Now use a more generic system where
those modifiers output a velocity attribute.
Advantages:
* Geometry and particle nodes can output velocity through the same mechanism,
or read the attribute coming from earlier modifiers.
* The velocity can be preserved through modifiers like subdivision surface or
auto smooth.
* USD and Alembic previously only output velocity from fluid simulation, now
they work with velocity from other sources too.
* Simplifies the code for renderers like Cycles and exporters like
Alembic and USD.
This breaks compatibility:
* External renderers and exporters accessing these velocities through the
Python API now need to use the attribute instead.
* Existing modifier node setups that create an attribute named "velocity"
will render differently with motion blur.
Differential Revision: https://developer.blender.org/D12305
When a vertex group is used to limit the influence of the modifier
to a subset of vertices, binding data for vertices with zero weight
is not needed. This wastes memory, disk space and CPU cycles.
If the vertex group contents is known to be final and constant,
it is reasonable to optimize by only storing data group vertices.
This has to be an option in case the group can change.
Supporting this requires adding a vertex index field and spliting
the vertex count into mesh and bind variants, but both happen to
fit in available padding. The old numverts field is renamed to the
new bound vertex count field to maintain the array length invariant.
Versioning is used to initialize the other new fields.
If a file with sparse binding is opened in an old blender version,
it is corrupted into a non-sparse bind with vertex count mismatch,
preventing the modifier from working until rebind.
Differential Revision: https://developer.blender.org/D11924
The `bisect_distance` in the mirror modifier was hard-coded to `0.001`.
This would result in some unexpected behavior like vertices close
to the mirror plane being deleted or merged.
The fix now adds a parameter to the mirror modifier to expose the
bisect distance to the user. The default is set to the previous
hard-coded value to not "change" previous files.
Ref D10201
This resulted in bad motion blur from alembic animation when imported
after rB83980506957c (because it was now OFF by default).
When imported in a version prior to rB83980506957c and saved, this was
still working fine.
Vertex interpolation option introduced in rBbab2260b59c7 was defaulting
to ON (correct) in that commit, but was lost in rB83980506957c.
Now switch this to ON by default again.
Note: if you have a file that was (incorrectly) imported with a version
after rB83980506957c you'll have to enable Vertex Interpolation option
on every MeshSequenceCache modifier by hand.
Maniphest Tasks: T86654
Differential Revision: https://developer.blender.org/D10876