The simplify modifier uses
`bke::curves_copy_point_selection` but didn't
build the `points_to_keep` index mask correctly.
This fixes the indices in the index mask and also
optimizes the edge cases of removing all the points/
keeping all the points.
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.
Similar to the recently introduced `Solver` enum. This is just friendlier
and doesn't require including `DNA_node_types.h` in the geometry
module header. There's no strong benefit to declaring these enums in
DNA in practice.
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
Header file is renamed to GEO_mesh_boolean_convert.cc and
files that included it are updated to use that path.
This is in preparation for bigger changes to the internal
boolean API, which make more sense as a "geometry" API
than a kernel API.
Pull Request: https://projects.blender.org/blender/blender/pulls/119336
When the "use_attribute" properties were added, boolean IDProperties
didn't exist. Then we didn't change it for a while because of forward
compatibility concerns. But currently we always convert boolean
properties to integer properties when saving anyway (since
2ea47e0def, so there is no issue with compatibility.
Using booleans makes working with the properties in the Python API
a bit friendlier.
Pull Request: https://projects.blender.org/blender/blender/pulls/119129
"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.
* Only works on machines with a Qualcomm Snapdragon 8cx Gen3 or above.
Older generation devices are not and will not be supported due to
some driver issues
* Requires VS2022 for building.
* Uses new MSVC preprocessor for sse2neon compatibility.
* SIMD is not enabled, waiting on conversion of blenlib to C++.
Ref #119126
Pull Request: https://projects.blender.org/blender/blender/pulls/117036
The angle of the outline modifier caps was computed in a [-pi, +pi)
interval, but this creates an unstable situation for angles close to
180. Small variation can lead the angle to flip from +180 to -180 and
change the direction of the semi-circle. Instead generate arcs always
in counter-clockwise direction and use angles in the [0, 2pi) intverval.
This creates stable directions for end caps and also allows larger
arcs where necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/119122
Fixes behavior of the outline modifier in some edge case:
- When the outline radius gets larger than the input stroke radius it
caused a negative offset, inverting the outline in thin areas like the
tips of the default stroke. The offset should always remain positive
or zero (collapses onto the input curve).
- When the outline collapses the modifier was skipping points on outside
corners, where at least one point should be added in all cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/119084
With the default GPv3 "Stroke" object the outline modifier generates
jittery strokes. It also generates full circles at various points along
the input stroke.
The outline modifier chooses a normal from the camera view. In the
default GPv3 stroke test the camera views the stroke from an angle.
In that case the curve has a significant Z component out of the plane,
which breaks normalization of the 2D component and causes excessive
miter scaling.
The full circles are caused by bad angles, the range should be `(-pi,pi)`
rather than `(0,2*pi)`.
Pull Request: https://projects.blender.org/blender/blender/pulls/119067
The arrays `modified_starts` and `modified_ends` was freed early
due to wrong variable scope, this leads to incorrect randomize length
effect in length modifier. Now fixed.
Pull Request: https://projects.blender.org/blender/blender/pulls/119054
The GPv3 envelope modifier was computing the correct number of strokes
to generate, but then not actually skipping over points. Result is that
all envelope strokes got added at the beginning instead of the whole
point range.
Pull Request: https://projects.blender.org/blender/blender/pulls/119023
This rewrites the Alembic and USD data importers to work with and
output GeometrySets instead of Meshes.
The main motivation for this change is to be able to import properly
point clouds, which are currently imported as Meshes, and curves
data, which suffer from a lot of issues due to limitations of
legacy curves structures (fixed by the new curves data-block) and are
also converted to Meshes. Further, for Curves, it will allow importing
arbitrary attributes.
This patch was primarily meant for Alembic, but changes to USD import
were necessary as they share the same modifier.
For Alembic:
There should be no behavioral changes for Meshes
Curves are imported as the new Curves object type
Points are imported as PointClouds
For USD:
There should be no behavioral changes for Meshes
Curves are imported as the new Curves object type
Note that the current USD importer does not support loading PointClouds,
so this patch does not add support for it.
For both Alembic and USD, knots arrays are not read anymore, as the new
Curves object does not expose the ability to set them. Improvements can
be made in the future if and when example assets are provided.
This fixes at least the following:
#58704: Animated Alembic curves don't update on render
#112308: Curves have offset animations (alembic / USD)
#118261: wrong motion blur from usd in cycles and reverting to the first
frame when disabeling motion blur
Co-authored-by: Jesse Yurkovich <jesse.y@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/115623
