| Age | Commit message (Collapse) | Author |
|---|
|
Noisy change, but safe, and better do it sooner than later if we are to
rework copying code. Also, previous commit shows this *is* useful to
catch some mistakes.
|
|
Optionally it'll also give name used for memory allocation.
|
|
Those shall not be considered while checking whether a to-be-made-local
ID will end up fully local, or still be partially used by linked data...
Even less since we already do have special handling of proxies later.
Fixes main remaining issue found with 04_01_H.lighting.blend Agent327
file, and allows us to switch back to optimized post-processing in
make_local code.
|
|
Again, Agent327's 04_01_H.lighting.blend shows some problem here, it
triggers several times the 'not used at all' assert in step 5 of secure
code, and with optimized version we lose the connection between
rigs and the main characters!
Will keep investigating on this, but for now let's try to give something
working to the studio.
|
|
This should not be needed imho, we already set POSE_RECALC flag
correctly there, but it still is missing actual update of poses in some
(complex and convoluted) cases. So at least for now, let's go with this
hack, it's not really harming anyone anyway.
Fixes crash in Agent327's 04_01_H.lighting.blend when making all local.
|
|
|
|
|
|
`cd_flag` tends to be used for CustomData flags in mesh area, while for
library_query those are rather callback flags...
|
|
Better to have clear way to tell whether flag is parameter for
BKE_library_foreach_ID_link(), parameter for its callback function, or
return value from this callback function.
|
|
Use new Main->relations ID usages mapping in BKE_library_make_local().
This allows a noticeable simplification in code, and can be up to twice
quicker as previous code (Make Local: All from 2 to 1 minute e.g. in a
huge production file with thousands of linked data-blocks).
Note that new code has been successfuly tested with several complex cases
(production files from Agent327), as well as some testcases from recent
bug reports related to that function. But as always, nothing beats real
usage by real users, so please check this before we release 2.79. ;)
Main areas that would be affected: Make Local operations (L shortcut in
3DView), and append from libraries.
|
|
Use Main->relations in BKE_library_foreach_ID_link(), when possible
(i.e. IDWALK_READONLY is set), and if the data is available of course.
This is quite minor optimization, no sensible improvements are expected,
but does not hurt either to avoid potentially tens of looping over e.g.
objects constraints and modifiers, or heap of drivers...
|
|
This shall fix both existing code (bpy mapping, and local/lib usages
checks), and new Main->relations generation.
|
|
The new MainIDRelations stores two mappings, one from ID users to ID
used, the other vice-versa.
That data is assumed to be short-living runtime, code creating it is
responsible to clear it asap. It will be much useful in places where we
handle relations between IDs for a lot of them at once.
Note: This commit is not fully functional, that is, the infamous, ugly,
PoS non-ID nodetrees will not be handled correctly when building relations.
Fix needed here is a bit noisy, so will be done in next own commit.
|
|
|
|
Things like `BLI_uniquename` had nothing, but really nothing to do in
BLI_path_util files!
Also, got rid of length limitation in `BLI_uniquename_cb`, we can use
alloca here to avoid overhead of malloc while keeping free size (within
reasonable limits of course).
|
|
generate invalid utf-8 ID name.
`check_for_dupid()` would roughly truncate existing name, without doing any utf-8 validation.
|
|
Was a waaaaayyyyy to much generic name for such a specific func, renamed
to much more descriptive BKE_libblock_relink_to_newid().
In near future (few weeks, to limit as much as possible silent mismatch
in branches), will rename BKE_libblock_relink_ex to BKE_libblock_relink,
this is the real generic data-block relinking func!
|
|
This aims at always ensuring that ID.newid (and relevant LIB_TAG_NEW)
stay in clean (i.e. cleared) state by default.
To achieve this, instead of clearing after all id copy call (would be
horribly noisy, and bad for performances), we try to completely remove
the setting of id->newid by default when copying a new ID.
This implies that areas actually needing that info (mainly, object editing
area (make single user...) and make local area) have to ensure they set
it themselves as needed.
This is far from simple change, many complex code paths to consider, so
will need some serious testing. :/
|
|
This makes heavy scenes to be freed almost instantly (so now
quadbot scene takes only 0.06sec to free),
|
|
Object freeing may in some kind access its obdata (in case it has some
caches e.g.), since here obdata may have already been freed, let's set
object's data pointer to NULL (probably not ideal solution, but we don't
care much, those form archipelagos of unused linked datablocks,
we nuke'em all anyway).
Also fix stupid mistake in one of own recent commits (using ID we just
freed, tsst...).
|
|
|
|
Do not set 'real user' to groups every time we run the first clearing loop.
And do fully clear properly LIB_TAG_DOIT (this is not yet enforced in
existing code, but would love to get to that stage in future, so let's
do it at least with new code!).
|
|
|
|
Basic idea is to split first loop in two, and run checks before making
anything actually local, to detect data-blocks that we can directly make
local (because we are sure they are only used by already/future local
datablocks).
This allows to avoid a lot of overhead in later 'cleanup' steps of this
function, here with barbershop shot it's four times quicker (from 190s to 48s).
We are still far from the instantaneous results of MakeLocal in 2.77,
but in that version main characters lose their connection to their
armature and remain static after makelocal, so guess new code is still
better. ;)
There are probably more optimizations possible here, but would rather
polish this area of code once we get rid of proxies, those really
make it a nightmare to work on.
|
|
This *should* work, but do not hesitate to revert in case it creates new
crashes in append or makelocal processes.
|
|
Proxified objects can never be local, we can totally ignore them here.
This 'fixes' the asserts related to usercount when trying to remap poselib
of localized proxified objects (not sure what exactly was going on wrong here,
but proxies are a giant can of worms for sane data-blocks handling anyway :/).
|
|
|
|
This is required since new dependency graph evaluates drivers in threads
so it was possible to have some partially written ID tag there.
|
|
New code dealing with getting rid of lib-only cycles of data-blocks
could add several time the same datablock to the list of candidates. Now
this is avoided, and pointers are further cleaned up as double-safety
measure.
|
|
Issue here was that py API code was keeping references (pointers) to the
liniked data-blocks, which can actually be duplicated and then deleted
during the 'make local' process...
Would have like to find a better way than passing optional GHash to get
the oldid->newid mapping, but could not think of a better idea.
|
|
clearing of linked data-blocks.
This is not a simple fix, but imho still needs to be backported to 2.78a...
|
|
those flags were set!
Dummy mistake, to be backported to 2.78a.
|
|
One day we'll have to reconsider why some many 'real' ID usages are not
refcounting... :(
To be backported to 2.78a.
|
|
Such a "referenced proxy" could be a proxy that is used in a constraint on
another object. Brings back part of 1cdc54dc7db85766 but without the
memory leak.
|
|
This allows appending of an entire scene from another blend file into this one,
even when that blend file contains proxified armatures.
This replaces the approach from commit 1cdc54dc7db85766.
Thanks @sergey for the help.
|
|
|
|
This allows appending of an entire scene from another blend file into
this one, even when that blend file contains proxified armatures.
Since the proxified object needs to be linked (not local), this will
only work when the "Localize all" checkbox is disabled. The appended
proxy object should also not be referenced from anything in a library
(for example in a constraint). Referencing it from the appended data
should be fine.
Fixes T49495.
|
|
The first character of the ID type was used to tag IDs for updates which
is weak since different IDs can have the same first character (for
example meshes, materials and metaballs), causing unnecessary updates of
unrelated IDs.
Now we use a unique index per ID type to tag for updates, unifying IDs
arrays indexing along the way.
Reviewers: sergey, mont29
Differential Revision: https://developer.blender.org/D2139
|
|
|
|
All in all, this patch adds an Alembic importer, an Alembic exporter,
and a new CacheFile data block which, for now, wraps around an Alembic
archive. This data block is made available through a new modifier ("Mesh
Sequence Cache") as well as a new constraint ("Transform Cache") to
somewhat properly support respectively geometric and transformation data
streaming from alembic caches.
A more in-depth documentation is to be found on the wiki, as well as a
guide to compile alembic: https://wiki.blender.org/index.php/
User:Kevindietrich/AlembicBasicIo.
Many thanks to everyone involved in this little project, and huge shout
out to "cgstrive" for the thorough testings with Maya, 3ds Max, Houdini
and Realflow as well as @fjuhec, @jensverwiebe and @jasperge for the
custom builds and compile fixes.
Reviewers: sergey, campbellbarton, mont29
Reviewed By: sergey, campbellbarton, mont29
Differential Revision: https://developer.blender.org/D2060
|
|
Previous check to skip non-linkable IDs resulted in not clearing those skipped ID's newid member,
wich lead to try to remap it later in code.
|
|
There were actually two issues, one in recent changes and one existing... forever?
I) id_make_local() would never proceed over indirectly linked data, which is required in specific 'append' context.
II) BKE_image_copy() was not setting id->newid pointer of newly copied ID.
About II: don't really know why image copy does its own cooking instead of using generaic ID copy helpers.
Think this should be changed, but that would be after 2.78 now.
|
|
This is a good point to change this as grease-pencil-v2 branch was just merged, so I hope merge conflicts with other branches are minimal.
|
|
|
|
As title says... Copying tracking data from movieclip was not the simplest thing...
Reviewers: sergey
Differential Revision: https://developer.blender.org/D2126
|
|
Hating all those not-so-real ID types... Here there were two causes for the issue:
1) Linked shapekey ID was made local twice (once from mesh's make local, once by itself).
Solved by not explicitely making shapekeys (nor any other non-linkable datatype) local.
2) Key->from 'back pointer' to its owner was messing 'still in used' detection of linked data
after localization. Fixed with a hack for now, thinking correct solution might actually
be to not consider this pointer at all in libquery ID looper, since it's nothing like
and actual usage of mesh/lattice/curve.
Again, shapekeys as ID is a joke, those should be mere struct, they have absolutely nothing to do in Main, period. :(
Point 2) still demonstrates the need for better handling of IDs dependencies though,
so far we only hit corner cases, but think there could also be valid cases generating those
'dependency cycles' between IDs (ID a using ID b which uses ID a), this will have to be addressed some day...
|
|
library.c
Note that all deprecated/non-real ID types are kept as defines.
|
|
Palette and PaintCurve were totally missing from id_copy/id_make_local switch... :/
|
|
BKE_id_copy_ensure_local function.
|
|
This is really not elegant solution, but simplest for now.
Ideally, we'd check all IDs first and directly 'make local' (without need to copy)
those only indirectly used by other datablocks to be made local. Would also save us from the
need of the extra 'lib_local' parameter recently added to id_make_local.
Current code seems to work well enough though, and this is not high priority to fix imho.
|
