Basically copy the information from the commit message of the
03e2f11d48 directly to the code.
This makes the information easier to find when working on the
code.
Swapping some ID lists between Mains must invalidate the name_map cache.
Note that in theory, at least WM type could be ignored by name_map
cache, since it is a singleton. However, don't think it's worth adding
extra complication here, for really marginal benefits. The overhead of
rebuilding the name cache here is extremly small.
For some reason, this issue did not show so far in master, only appeared
in some branch work on improving (in)direct status of linked IDs... Go
figure.
a5e7657cee didn't account for slices of zero sizes, and the asserts
were slightly incorrect otherwise. Also, the change didn't apply to
`Span`, only `MutableSpan`, which was a mistake. This also adds "safe"
methods to `IndexMask`, and switches function calls where necessary.
This is not used for anything in practice currently. The original intention
was probably to generate different socket subtypes, but that is solved
differently now (e.g. using `NodeSocketFloatDistance`). It's possible
that an addon tried to use this but it's rather unlikely.
Differential Revision: https://developer.blender.org/D13188
Before this, if there were no missing files, the operator would run
successfully but there would be no user feedback at all, making the
user wonder if the operator was even run.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D16585
`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.
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.
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
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.
The function is already doing a lot of memory indirections and
sub-optimal lookups, so for the simplicity and robustness of the
system might as well just do copy-on-write update.
The refactor in f1c0249f34 incorrectly placed the material index
remapping before the transfer of generic attributes. Now that the
material index is a generic attribute, it was overwritten.
The node level was an indication of how deep the node was in the tree.
It was only used for detecting link cycles. Now that the node topology
cache from 25e307d725 exists, this calculation can be removed
completely.
The level calculation was quadratic and very slow on larger node trees.
In the mouse house file with a few thousand nodes, it took 23ms on
every single update. Another benefit is storing slightly less runtime
data, though this was only 2 bytes per node.
Differential Revision: https://developer.blender.org/D16566
Instead of generating a dependency sorted node list whenever evaluating
texture or EEVEE/viewport shader nodes, use the existing sorted array
from the topology cache. This may be more efficient because the
algorithm isn't quadratic. It's also the second-to-last place to
use `node.runtime->level`, which can be removed soon.
Differential Revision: https://developer.blender.org/D16565
Remove `private:` from the PBVHFaceIter. This is not really a C++
class, and the C++ code generates a lot of warnings about unused
fields.
Also mark function static and run clang-format.
