- No need for `normal_tx` array if we normalize the planes in `plane_tx`.
- No need to calculate the distance squared to a plane (with `dist_signed_squared_to_plane_v3`) if the plane is normalized. `plane_point_side_v3` gets the real distance, accurately, efficiently and also signed.
So normalize the planes of the member `CameraViewFrameData::plane_tx`.
Previously, the number of action map subactions was limited to two per
action (identified by user_path0, user_path1), however for devices with
more than two user paths (e.g. Vive Tracker) it will be useful to
support a variable amount instead.
For example, a single pose action could then be used to query the
positions of all connected trackers, with each tracker having its own
subaction tracking space.
NOTE: This introduces breaking changes for the XR Python API as follows:
- XrActionMapItem: The new `user_paths` collection property
replaces the `user_path0`/`user_path1` properties.
- XrActionMapBinding: The new `component_paths` collection property
replaces the `component_path0`/`component_path1` properties.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D13949
After running the breakdown operator for the graph editor,
the factor property in the redo panel didn't reflect the value you chose
to mitigate that issue down the line there is a
new helper function to get the factor value, and
store it at the same time
Reviewed by: Sybren A. Stüvel
Differential Revision: https://developer.blender.org/D14105
Ref: D14105
Brew's Python framework's site-packages is a symlink so the assumption
that Resources and site-packages would be in the same directory
doesn't hold. So install scripts etc relative to bpy.so. Part of D14111
StringGrid has been deprecated in openvdb 9.0.0 and will be removed soon
Reviewed By: Brecht
Differential Revision: http://developer.blender.org/D14133
The general idea here is to wrap the `CurvesGeometry` DNA struct
with a C++ class that can do most of the heavy lifting for the curve
geometry. Using a C++ class allows easier ways to group methods, easier
const correctness, and code that's more readable and faster to write.
This way, it works much more like a version of `CurveEval` that uses
more efficient attribute storage.
This commit adds the structure of some yet-to-be-implemented code,
the largest thing being mutexes and vectors meant to hold lazily
calculated evaluated positions, tangents, and normals. That part might
change slightly, but it's helpful to be able to see the direction this
commit is aiming in. In particular, the inherently single-threaded
accumulated lengths and Bezier evaluated point offsets might be cached.
Ref T95355
Differential Revision: https://developer.blender.org/D14054
Finding the greatest and/or smallest element in an array is a common
need. This commit refactors the point cloud bounds code added in
6d7dbdbb44 to a more general header in blenlib.
This will allow reusing the algorithm for curves without duplicating it.
Differential Revision: https://developer.blender.org/D14053
This is meant to complement the `blender::math` functions recently
added by D13791. It's sometimes desired to template an operation to work
on vector types, but also basic types like `float` and `int`. This patch
adds that ability with a new `BLI_math_base.hh` header.
The existing vector math header is changed to use the `vec_base` type
more explicitly, to allow the compiler's generic function overload resolution
to determine which implementation of each math function to use.
This is a relatively large change, but it also makes the file significantly
easier to understand by reducing the use of macros.
Differential Revision: https://developer.blender.org/D14113
Fix possible overflow of Modifier UUID
The code prior this change was re-generating modifier's session UUID
prior to copying this id from the source. This approach has a higher
risk of modifiers session UUID to overflow and start colliding with
existing modifiers.
This change makes it so that modifier copy does not re-generated the
session UUID unless it is needed.
Differential Revision: https://developer.blender.org/D14125
Due to recent changes there have been reports of incorrect loading of
GPU textures. This fix reverts a part of {D13238} that might be the
source of the issue.
This does not happen with **any** image, but with images that have ID
properties.
ID properties are used to store view projection matrices (e.g. for
reprojection with `Image from View` or `Quick Edit` -- these are the
ones we are interested in), but of course they can be used for anything
else, too. The images in the file from the report have ID properties from
an Addon for example.
So the crash can reliably be reproduced with **any** image doing the
following:
```
bpy.data.images['myImage']['myIDprop'] = "foo"
```
This would lead code in `texture_paint_camera_project_exec` to think the
needed `view_data` is on the image (but in reality it was just some
other IDprop).
Solution is simple: just check `view_data` is really valid after getting
it from the IDprops.
Maniphest Tasks: T95787
Differential Revision: https://developer.blender.org/D14116
Having this setting stored in the image space caused low level selection
logic to have to pass around the image space (which could be NULL
in some cases). Use the tool-settings instead since there doesn't seem
to be much/any advantage in having this setting per-space.
Although rB56407432a6a did fix missing subdivision in some cases, in
other cases it did not return the mesh wrapper (like when using
autosmooth, which requires a copy of the mesh), so the non-subdivided
mesh was still returned.
Not all coarse vertices were used to compute the center value (off by
one), and the interpolation for the current would always start at the
base corner for the base face instead of the base corner for the current
patch.
This patch reverses the dependency between `BLI_math_vec_types.hh` and
`BLI_math_vector.hh`. Now the higher level `blender::math` functions
depend on the header that defines the types they work with, rather than
the other way around.
The initial goal was to allow defining an `enable_if` in the types header
and using it in the math header. But I also think this operations to types
dependency is more natural anyway.
This required changing the includes some files used from the type
header to the math implementation header. I took that change a bit
further removing the C vector math header from the C++ header;
I think that helps to make the transition between the two systems
clearer.
Differential Revision: https://developer.blender.org/D14112
This commit renames `mesh_validate.cc` to `mesh_calc_edges.cc`.
I would like to move `mesh_validate.c` to C++, but it makes sense to
keep this specific algorithm in a smaller file.
This adds a new sculpt mode to the experimental new curves object.
Currently, this mode can only be entered and exited, nothing else.
The main initial purpose of this node will be to use it for hair grooming.
The patch also adds the `editors/curves/` directory for the new curves
object, which will be necessary for many other things as well.
I added a completely new mode (`OB_MODE_SCULPT_CURVES`), because
`OB_MODE_SCULPT` seems to be rather specific to meshes, and reusing
it doesn't seem worth the trouble. The tools/brushes used in mesh vs.
curves sculpt mode are quite distinct as well.
I had to add DNA_userdef_enums.h to make the patch compile with C++
(forward declaration of enums isn't allowed). This follows the same
pattern that we use for other enums in dna.
Differential Revision: https://developer.blender.org/D14107
Since the output file stays unmodified for most developer builds,
install step installed it redundantly.
Create readme.html using `configure_file`:
- Now it's modified only if final output changes (handled by CMake).
- If input file (from git) or blender version changes,
it //will// be modified.
Also don't re-implement what CMake can do.
Reviewed By: campbellbarton, LazyDodo
Differential Revision: https://developer.blender.org/D13863
