Mostly pass bmain and do not check for NULL key, keys' make_local is
suspiciously simple in fact, but think until those behave like real
full-featured IDs, it's doing enough!
At first thought it was own recent work, but think issue is there since ages actually...
Basically, id_make_local() would always localize mesh/curve/lattice shapekeys, even in case
obdata localization actually made a local copy instead of localizing original datablock.
This was causing shapekeys being localized twice, and other odd nasty effects.
libquery now passes an extra flag info to the callback, in case that specific
ID usage is considered as indirect.
In most cases, it's just set from ID_IS_LINKED_DATABLOCK() result on datablock owner,
but in proxy object case we also consider ob->data, materials and pose usages as indirect.
Does not fixes all issues yet, but should already make behavior with proxy object saner.
Now using modern features from libquery/libremap areas.
Provides same kind of fixes/improvements as for BKE_object_make_local() (see rBd1a4ae3f395a6).
Note: this enlightened broken case of proxy objects regarding make_local
(and also whole remapping, in fact). Will be fixed in near future.
Not really happy with this, could lead to a **lot** of callback executions...
But libquery foreach looper must go over **all** ID pointers,
otherwise remapping & co is broken!
A possible fix for future would be to have 'image slots' defined at root of poly/facetex layers,
and just a (short) index in each face/poly item - would also save a reasonable amount of memory...
Now using modern features from libquery/libremap areas.
Also, it should handle much better cases where localized ID was also indirectly used by non-refcounting users
(typical case: object used as modifier/constraint/whatever target from another linked object, previous
code would not take those into account and just localize original object instead of making a local copy.
Would result in local object used by linked one, which would be partially 'undone' on next file reload... Crappy behavior).
And it fixes some obvious errors too (nullifying all proxy pointers unconditionnaly,
some missing refcounted usages cases in extern_local_object(), etc.).
Totally stupid to not pass it, and then let (some) BKE_foo_make_local() use G.main!
Note: unused for now, much more refactoring still to come in make_local area!
Now test_object_materials only handles one object. New test_all_objects_materials
checks the whole bmain->object list for cases where it is actually needed.
Should avoid some useless looping over all objects!
Main issue was that BKE_libblock_relink_ex was pretty much ignoring all those...
Also, unlinking of objects was not handling correctly indirect-related flags.
Refactored code into helper functions to avoid too much duplicated code.
This should allow us to avoid a lot of useless processing when iterating over the
whole main database (unlink/remap/usages checks/etc.).
Note that some ID types report they can use any type for now, due to
fuzzyness/indefined nature of some usages (like constraints/modifiers/game logic,
or ID pointer of nodes...). Maybe we could address this (like e.g. adding defines
in relevant headers to restrict ID types used by constraints, by modifiers, etc.).
But don’t think this is top priority for now.
Idea is to replace hard-to-track (id->lib != NULL) 'is linked datablock' check everywhere in Blender
by a macro doing the same thing. This will allow to easily spot those checks in future, and more importantly,
to easily change it (see work done in asset-engine branch).
Note: did not touch to readfile.c, since there most of the time 'id->lib' check actually concerns the pointer,
and not a check whether ID is linked or not. Will have a closer look at it later.
Reviewers: campbellbarton, brecht, sergey
Differential Revision: https://developer.blender.org/D2082
Checking if faces exist was a bottleneck,
use a simpler version of this function for triangles.
Gives approx 1.6x overall speedup (when many edges are being collapsed).
Two were actual bugs, though they existed only in unused code:
* In Freestyle it was unintentionally copying a scene rather than referencing it.
* In BLI_array_store_is_valid there was use of uninitialized memory.
As pointed by Brecht, previous fix in rB61b49de44940 was actually incomplete,
we could still hit float rounding issue and hence same value in more than one consecutive
items of element_sum.
New solution is a bit different, we remove the 'minimal weight' check, and rather simply
ignores an item when the sum of its normalized weight to previous item's sum does not add
anything. Shall be safe and 100% effective this time!
This is in fact very hairy situation here... Objects are only refcounted by scenes,
any other usage is 'free', which means once all object instanciations are gone Blender
considers it can delete it.
There is a trap here though: indirect usages. Typically, we should never modify linked data
(because it is essencially useless, changes would be ignored and ost on next reload or
even undo/redo). This means indirect usages are not affected by default 'safe' remapping/unlinking.
For unlinking preceeding deletion however, this is not acceptable - we are likely to end with
a zero-user ID (aka deletable one) which is still actually used by other linked data.
Solution choosen here is double:
I) From 'user-space' (i.e. outliner, operators...), we check for cases where deleting datablocks
should not be allowed (indirect data or indirectly used data), and abort (with report) if needed.
II) From 'lower' level (BKE_library_remap and RNA), we also unlink from linked data,
which makes actual deletion possible and safe.
Note that with previous behavior (2.77 one), linked object would be deleted, including from linked data -
but then, once file is saved and reloaded, indirect usage would link back the deleted object,
without any instanciation in scene, which made it somehow virtual and unreachable...
With new behavior, this is no more possible, but on the other hand it means that in situations of dependency cycles
(two linked objects using each other), linked objects become impossible to delete (from user space).
Not sure what's best here, behavior with those corner cases of library linking is very poorly defined... :(
changes in BLI_kdopbvh:
- `BLI_bvhtree_find_nearest_to_ray` now takes is_ray_normalized and scale argument.
- `BLI_bvhtree_find_nearest_to_ray_angle` has been added (use for perspective view).
changes in BLI_bvhutils:
- `bvhtree_from_editmesh_edges_ex` was added.
changes in math_geom:
- `dist_squared_ray_to_seg_v3` was added.
other changes:
- `do_ray_start_correction` is no longer necessary to snap to verts.
- the way in which the test of depth was done before is being simulated in callbacks.
So the error seems to be in cubic_tangent_factor_circle_v3(),
which was introduced with D2001.
I've tweaked the most obvious culprit here - the epsilon factor.
It used to be 10^-7, but I've reduced it down to 10^-5 now,
and it's looking a lot more stable now :)
---------
BTW, about the derivation of the magic 0.390464 factor I briefly subbed back
as a workaround for this bug, see:
http://www.whizkidtech.redprince.net/bezier/circle/
It's probably some numeric precision issue, but until we figure out exactly what's
going wrong here, let's just revert back to the hardcoded value that was used here
successfully for years without issues.
Remapping indirect usage of IDs is forbidden from user space, this is calling for
nice nightmare with libraries handling (and undo crash, among other things).
Not sure why I was 'laxist' about indirect usage cases detection like that,
for now just consider any ID used by another linked datablock as indirect usage case!
Also, added some error/warning reports to Outliner's remap code.
