This commit makes some tweaks that make it at least possible to use lib-linked
actions as Pose Libraries. Specifically:
* The apply poses button is no longer greyed out
* It is possible to select different poses from the list of poses
* All pose library operators which edit the poses stored in the poselib
now have improved poll callbacks which perform extra checks for lib-linked
actions (which cannot be edited, as all those changes will be lost)
Caveats:
* Due to the way the UI list template works, it doesn't seem to be possible to
make it not grey out the items in the list. (While the double-click to rename
thing shouldn't be allowed, items should at least look like they can be clicked on)
* The difference between clickable vs not-clickable isn't too great, making it hard
to tell that that while the Add/Remove/Sanitise toggles are not usable,
the Apply Poses is actually functional. But, this is a more of a UI-toolbox
level issue
This commit simplifies the logic for finding the control curves for NLA strips,
thus eliminating a whole bunch of weird errors that were happening here. It should
also fix a number of other related issues here.
By default watertight intersections are used,
For callbacks where its not needed,
BLI_bvhtree_ray_cast_ex can be called without the BVH_RAYCAST_WATERTIGHT flag.
Fixes T45286
The callback checks if 2 nodes intersect (not just their AABB).
Advantages:
- theres no need to allocate overlaps which are later ignored.
- expensive intersection tests will run multi-threaded.
Currently only used for Python API.
In the file of the report, stencil and clone indices
have fallen out of synch with the uv/mtexpoly layers.
Looks like the file has a long history, coming from 2.49
even. Unfortunately reporter cannot recall exact steps
to reproduce, so "fix" is to patch mesh.validate to
fix those indices.
Was performing ray-tri intersection checks on all faces.
Note, this isn't using isect_ray_tri_threshold_v3
which was used to prevent ray-casts slipping through between faces.
Instead we'll move to using watertight intersections by default.
An entry could already exist in misc cache, when creating it for block cache, leading to double-creation.
Issue was not that serious (no memleak or so), but nasty still. Thanks to Severin for notifying the assert.
It basically rewrites most of filelist.c, with some more limited changes in other areas of filebrowser.
From user perspective, it:
* Removes some info in 'long' drawing mode (owner, permissions) - OS-specific data that do not really matter in Blender!
* Makes short/long display 'fixed' size (among four choices, like thumbnails mode).
* Allows to list several layers of dirtree at once, in a flat way (inside .blend files and/or real directories).
* Consequently, adds datablocks types filtering.
* Uses way less RAM when listing big directories, especially in thumbnail mode (we are talking of several hundred of MiB spared).
* Generates thumbnails way faster.
From code perspective, it:
* Is ready for asset engine needs (on data structure level in filebrowser's listing).
* Simplifies and makes 'generic' file listing much lighter.
* Separates file listing in three different aspects:
** 'generic' filelisting (in BLI), which becomes a shallow wrapper around stat struct.
** 'filebrowser drawing' filelisting, which only contains current visible subset of the whole list (sliding window), with extra drawing data (strings for size, date/time, preview, etc.).
** 'asset-ready' filelisting, which is used for operations common to 'basic' filehandling and future asset-related one.
* Uses uuid's to handle file selection/state in the browser, instead of using flags in filelisting items.
* Uses much lighter BLI_task handling for previews, instead of heavy 'job' system (using the new 'notifier' timer to handle UI refresh, in similar way to jobs).
* Moves .blend datablocks preview handling to IMB_thumbnail (necessary to avoid storing all datablock previews at once, and gives better consistency and performances too).
Revision: https://developer.blender.org/D1316
Thanks to Campbell & Sergey for the reviews. :)
If we had ambiguity in the SceneRenderView > Suffix matching test, the
first match would be used. And this would happen everytime a
SceneRenderView had an empty camera suffix.
We now take the longest matching suffix instead.
Notes:
* Not yet used, this is the last piece of 'side changes' before the big filebrowser commit.
* We can probably be more effective here (like e.g. reading and storing all previews for a given
group in thumbnails cache at once, instead of re-opening and parsing the whole file each time),
but will do this later.
General idea is that, if several threads are handling thumbnails at the same time,
they can end working on the same file at some point, which will generate conflict.
To avoid this, threads can now lock a given filepath.
Note that locking data is allocated on a ref-count basis, to avoid keeping the GSet
in memory when not needed. Also, we are using global LOCK_IMAGE mutex for now.
Needed for upcomming filebrowser rework.
