`GeometrySet::has()` can return an empty component. It's more convenient
if it doesn't, since other code rarely wants to access an empty component.
The alternative would be adding an `is_empty()` check in the lazy function
for the viewer node, that would work fine too, for this case.
Differential Revision: https://developer.blender.org/D16584
When combining the internal geometry component instancing (used when
the original object type doesn't match the evaluated data type) with
the "vertex dupli" instancing could cause the fix from e508de0417
to fail, because the subsequent fix from 864af51d6a popped from the
"instance generator type" stack even when there was nothing added to it
(for geometry instancing).
Currently the face set of every single face is saved for every sculpt undo step.
When only changing the face sets of a small section of the mesh, this can be quite
wasteful. It also makes face sets a special case compare to all other sculpt undo step
types, which makes the whole system more complex and harder to improve.
Fixes T101203.
Reviewed By: Hans Goudey
Differential Revision: https://developer.blender.org/D16224
Ref D16224
Currently the face set of every single face is saved for every sculpt undo step.
When only changing the face sets of a small section of the mesh, this can be quite
wasteful. It also makes face sets a special case compare to all other sculpt undo step
types, which makes the whole system more complex and harder to improve.
Fixes T101203.
Reviewed By: Hans Goudey
Differential Revision: https://developer.blender.org/D16224
Ref D16224
We currently check multiple dynamic attribute providers for the
attribute ID, even after it has been removed (which can free the name).
This was used as a simple way to remove multiple attributes with the
same name (dealing with name collisions). However, that doesn't happen
in practice at this point, since so much code has moved to the
attribute API which checks for it.
Since we free BMesh attributes by attempting on every domain,
sometimes the attribute wouldn't be found for a CustomData.
We avoid reallocating custom data blocks in that case, so we
need to pass the ownership of the "pool" back to the BMesh.
Wrote a new API method, BKE_pbvh_sync_visibility_from_verts
that flushes vertex hidden flags to edges & faces.
Fixes not being able to sculpt outside a face set after
undoing the fkey hide-all-but-this operator.
Wrote a new API method, BKE_pbvh_sync_visibility_from_verts
that flushes vertex hidden flags to edges & faces.
Fixes not being able to sculpt outside a face set after
undoing the fkey hide-all-but-this operator.
Currently slicing a span clamped the final size so that it would be
within bounds of the input. However, in the vast majority of cases
that is already the case anyway, and we can use asserts to detect
when that assumption fails.
The clamping had a performance cost. On a test interpolating a boolean
attribute from 1 million curves to 4 million points, removing the
clamping saved about 10% of the time. That's an extreme case but
this probably slightly improves performance in other cases too.
Slicing is used a lot in the new curve code.
This commit introduces `slice_safe` which still does the clamping,
and uses it in the few places that needed it or where I wasn't
sure.
MoltenVK is part of the vulkan SDK. Blender requires the vulkan SDK
to compile. This patch adds the MoltenVK includes and libraries to
the Vulkan includes and libraries.
This avoids need to do special trickery detecting whether the principal
point is to be changed when reloading movie clip. This also allows to
transfer the optical center from high-res footage to possibly its lower
resolution proxy without manual adjustment.
On a user level the difference is that the principal point is exposed in
the normalized coordinates: frame center has coordinate of (0, 0), left
bottom corner of a frame has coordinate of (-1, -1) and the right top
corner has coordinate of (1, 1).
Another user-visible change is that there is no more operator for setting
the principal point to center: use backspace on the center sliders will
reset values to 0 which corresponds to the center.
The code implements versioning in both directions, so it should be
possible to open file in older Blender versions without loosing
configuration.
For the Python API there are two ways to access the property:
- `tracking.camera.principal_point` which is measured in the normalized
space.
- `tracking.camera.principal_point_pixels` to access the pixel-space
principal point.
Both properties are not animatable, so there will by no conflict coming.
Differential Revision: https://developer.blender.org/D16573
Before this an attempt to assign track from another object wos
silently assigning active object to null. Such silencing of
errors is not really a good way.
De-duplicate selection logic and threshold between various
operators (selection and sliding).
The user measurable difference is that regular selection
threshold now matches sliding threshold: it is more strict
now. The possible downside of this is that it might be more
tricky to select tracks, but this is what needs to happen
for tools support. Also, this matches object selection in
viewport.
Use active object accessor, and then access data from the
object. There is no need to have an API call for shortcut
of all object fields.
Should be no functional change.
Make it more obvious in the name that an operation is not
cheap, and that the function operates on a tracks from
object and does not need a global tracking structure.
Historically tracks and reconstruction for motion tracking camera
object were stored in the motion tracking structure. This is because
the data structures pre-dates object tracking support, and it was
never changed to preserve compatibility.
Now the compatibility code supports more tricks and allows to change
the ownership without breaking any compatibility. This is what this
change does: it moves tracks from motion tracking structure to the
motion tracking camera object, and does it in a way that no
compatibility is broken.
One of the side-effects of this change is that the active track is
now stored on motion tracking object level, which allows to change
active motion tracking object without loosing active track. Other
than that there are no expected user-level changes.
