When an edge was collapsed, one of the vertices would be removed.
Edges attached to the deleted vertex wouldn't be considered for collapsing again,
making the outcome from collapsing edges depend on the edge-vertex order.
Use a hash to lookup the final vertex when collapsing edges, instead of skipping them.
The shader sync code used the anisotropic version of the Ashikhmin-Shirley closure for both
Anisotropic and Glossy BSDF, which caused a failed assert because the anisotropic closure
expects an addiitonal SVM node.
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!
* Alt-G, Alt-R, Alt-S --> These don't clear delta transforms by default anymore,
making it possible to use these to properly store a "rest" pose
* Alt-Shift-G, Alt-Shift-R, Alt-Shift-S --> These WILL clear both the normal
transform and the delta, should you need to do so.
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.
Toggling edit-node after joining objects is redundant as far as I can see -
(dates back to first revision).
Also caused all edges to be drawn w/ meshes, redundant undo step w/ curves.
`my_memcmp` didn't work properly comparing memory sizes not aligned to 4 bytes,
this worked while we used guarded-alloc (which always wrote a guard at the end of each allocation).
Since moving to lockfree allocator it could read uninitialized memory.
It also consistently performed ~10-30% worse then glibc's.
This is typically well optimized, no need to do ourselves.
Scaling a bone on the Y axis (for a stretch effect), wasn't supported by the IK solver.
Support this by solving as uniform scaled bones by matching the X,Z axis to the Y.
Requested by @pepeland, see D2088 for details.
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.
