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.
Rewrite the edge split code to operate directly on Mesh instead
of BMesh. This allows for the use of multi-threading and makes
the node around 2 times faster. Around 15% of the time is spent
just on the creation of the topology maps, so these being cached
on the mesh could cause an even greater speedup. The new node
gave identical results compared to the BMesh version on all the
meshes I tested it on (up to permutation of the indices).
Here are some of the results on a few simple test cases:
(Intel i7-7700HQ (8 cores) @ 2.800GHz , with 50% of edges selected)
| | 370x370 UV Sphere | 400x400 Grid | Suzanne 4 subdiv levels |
| ----- | ----------------- | -------------- | --------------------- |
| Mesh | 89ms | 111ms | 76ms |
| BMesh | 200ms | 276ms | 208ms |
Differential Revision: https://developer.blender.org/D16399
This patch adds basic face iterators to the sculpt API. The interface is similar to the existing vertex iterators. It's not C++ (though it does mark private fields in PBVHFaceIter as private if compiling under C++).
Example:
```
PBVHFaceIter fd;
BKE_pbvh_face_iter_begin(pbvh, node, fd) {
/* Face reference and face index */
PBVHFaceRef face = fd->face;
int face_index = fd->index;
/* Can read and modify hide flag if it exist (it may not) */
if (fd->hide) {
*fd->hide ^= true; /* toggle hide */
}
/* Can read and modify face set if it exists */
if (fd->face_set) {
*fd->face_set = something;
}
/*Can read vertices*/
for (int i=0; i<fd.verts_num; i++) {
float *co = SCULPT_vertex_co_get(ss, fd.verts[i]);
}
}
BKE_pbvh_face_iter_end(fd);
```
Reviewed By: Brecht Von Lommen and Hans Goudey
Differential Revision: https://developer.blender.org/D16225
Ref D16225
Use the shared cache system introduced in e8f4010611 for the
"looptris" triangulation cache. This avoids recalculation when meshes
are copied but the positions or topology don't change. The most obvious
improvement is for cases like a large meshes being adjusted slightly
with a simple geometry nodes modifier. In a basic test with a transform
node with a 1 million point grid I observed an improvement of 13%, from
9.75 to 11 FPS, which shows that we avoid spending 6ms recalculating
the triangulation of every update.
This also makes the thread safety for the triangulation data use a
more standard double-checked lock pattern, which is nice because we
can avoid holding a lock whenever the cached data is retrieved.
Split from https://developer.blender.org/D16530
As part of T95966, this patch moves loose edge information out of the
flag on each edge and into a new lazily calculated cache in mesh
runtime data. The number of loose edges is also cached, so further
processing can be skipped completely when there are no loose edges.
Previously the `ME_LOOSEEDGE` flag was updated on a "best effort"
basis. In order to be sure that it was correct, you had to be sure
to call `BKE_mesh_calc_edges_loose` first. Now the loose edge tag
is always correct. It also doesn't have to be calculated eagerly
in various places like the screw modifier where the complexity
wasn't worth the theoretical performance benefit.
The patch also adds a function to eagerly set the number of loose
edges to zero to avoid building the cache. This is used by various
primitive nodes, with the goal of improving drawing performance.
This results in a few ms shaved off extracting draw data for some
large meshes in my tests.
In the Python API, `MeshEdge.is_loose` is no longer editable.
No built-in addons set the value anyway. The upside is that
addons can be sure the data is correct based on the mesh.
**Tests**
There is one test failure in the Python OBJ exporter: `export_obj_cube`
that happens because of existing incorrect versioning. Opening the
file in master, all the edges were set to "loose", which is fixed
by this patch.
Differential Revision: https://developer.blender.org/D16504
* This patch just moves runtime data to the runtime struct to cleanup
the dna struct. Arguably, some of this data should not even be there
because it's very use case specific. This can be cleaned up separately.
* `miniwidth` was removed completely, because it was not used anywhere.
The corresponding rna property `width_hidden` is kept to avoid
script breakage, but does not do anything (e.g. node wrangler sets it).
* Since rna is in C, some helper functions where added to access the
C++ runtime data from rna.
* This size of `bNode` decreases from 432 to 368 bytes.
This allows for optimizations because one does not have to iterate
over all nodes anymore to find all nodes within a frame.
Differential Revision: https://developer.blender.org/D16106
Add a new flag value `CUMA_REMOVE` to explicitly tag duplicate points
for removal. This prevents a bug where all curve points with vector
handles were deleted, when removing duplicate curve points while
updating the widget. This happened, because the flag value used to tag
points for removal was the same as the value of `CUMA_HANDLE_VECTOR`
used to store the handle type of the curve point.
Reviewed By: Hans Goudey
Differential Revision: http://developer.blender.org/D16463
Add a new flag value `CUMA_REMOVE` to explicitly tag duplicate points
for removal. This prevents a bug where all curve points with vector
handles were deleted, when removing duplicate curve points while
updating the widget. This happened, because the flag value used to tag
points for removal was the same as the value of `CUMA_HANDLE_VECTOR`
used to store the handle type of the curve point.
Reviewed By: Hans Goudey
Differential Revision: http://developer.blender.org/D16463
The 1a1341c387 made it so that when ID's path changes the ID is
tagged for the source re-evaluation. Another factor here is that
there is a code in the read file which replaces alternative path
slash with the native one.
Typically it is not a problem since IDs are re-evaluated on load,
but the movie clip has the special handling on load to calculate
the image sequence length and initialize principal point.
This change makes it so that the principal point is only reset
when the clip resolution changes. This is something which is
also useful for cases when a non-centered primncipal point is
used and someone accidentally clicks on the clip reload button.
It is not really ideal but covers most of the common cases.
Ideally the principal point will be stored in relative or
normalized space.
The remaining part is that there is now extra image sequence
length calculation after file load. This needs more careful
look.
Remove unnecessary (and No-op) normal calculation when sculpting on top
of deformed coordinates. Examples are shape keys and deform modifiers.
On a 1 million face mesh, this saved 100ms per stroke update.
This function actually did nothing since cfa53e0fbe,
so that large improvement comes for free.
Conceptually this is correct because when sculpting on deformed
coordinates, we don't change the positions of the base mesh directly.
In the future it might be better to allocate a separate array for
normals when using deformed coordinates, but it's not clear that's
necessary yet.
10131a6f62 replaced use of the `ME_EDGERENDER` flag with
`ME_EDGEDRAW`. However, left over from previous refactors, code
for leaving edit mode set that flag based on the edge angle. Edge angle
wireframe hiding is currently supposed to be adjustable with the
wireframe overlay settings. This patch restores the previous behavior
from before the cleanup commit.
Differential Revision: https://developer.blender.org/D16451
This reverts commit 676137f043.
This change worked locally with a specific test file and local changes,
but didn't work in general, since we don't reliably retrieve the new
looptris after setting them the first time. This can be improved again
in the future, but probably along with a more general look about ownership
is handled with PBVH.
