This is mainly required for the new dependency graph where non-object
datablocks are a part of dependency graph.
This solves issue when making mesh shared by multiple objects a single
user one.
Wasn't copying back local view bytes to object after changing layer.
Steps to reproduce were:
* Split 3D view in default startup.blend
* Enter local view in one of the 3D views
* Move default cube to different layer *in the other 3D view* (the one that's not in local view)
* Try transforming object from 3D View that's in local view (should lag)
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
* 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.
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!
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
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... :(
The Ctrl-Shift-C operator to add constraints between a pair of selected items,
for example, between two objects, or between two bones (in the same armature).
This commit makes it possible to use this operator to add a constraint where the
target is a bone from another object - e.g. to make a deform bone follow the control
bone in another armature, or to make an object use a bone as a tracking target.
Usage:
1) Ensure you are in Pose Mode, then select the bone to use as the target
2) Shift-Select the other object and/or the bone that's going to get the constraint
3) Ctrl-Shift-C
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
A new option for Font/Text objects vertical alignment:
* Top Base-Line (current mode)
* Top
* Center
* Bottom
The Top is the equivalent as the Top-Baseline with an empty line at the begin of the
text. It's nice to have this option too though, since if we are driving
the alignment via Python we don't want to add extra lines to the text
only to accomodate to the desired vertical alignment.
The Center and Bottom are as intuitive as their name suggest.
When working with text boxes, the vertical alignment only work for
paragraphs that are not vertically full.
Many thanks to Campbell Barton (ideasman42 / @campbellbarton) for the
code review, code comments, and overall suggestions and changes :)
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D2061
Being granular means we need to re-build depsgraph a bit more often..
The issue was caused by rigidbody requiring some special nodes to
handle physics which were not created with just tagging object for
update.
Now CD_SHAPEKEY_INDEX customdata is stored in edit-mode when hooks and vertex parents are used.
This also fixes a bug where undo would loose key-index data.
Move to structs for BM_mesh_bm_to/from_me to avoid passing many argument, which mostly aren't used.
This commit:
* Fixes bad handling of 'stop iteration' (by adding a status flag, so that we can actually
stop in helper functions too, and jumping to a finalize label instead of raw return, to
allow propper clean up).
* Adds optional recursion into 'ID tree' - callback can also decide to exclude current id_pp
from recursion. Note that this implies 'readonly', modifying IDs while recursing is not
something we want to support!
* Changes callback signature/expected behavior: return behavior is now handled through flags,
and 'parent' ID of id_pp is also passed (since it may not always be root id anymore).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1869
This has several benefits:
* User count remains coherent, regardless of the order in which you use 'user_one' & real refcounting users
(i.e. if you add to group, and then link in scene, or the reverse, you now always get same final user count).
* Avoids the need to check for potential 'user_one' extra user in count in several places in code (e.g. when
making IDs single users...).
* Users won't wonder why they cannot make 'single user' and ID even though its user count shows '2'!
* readfile.c now always uses code from BKE's library.c when modifying id->us. Which means we can consider
(asside from assignment during initialization) that id->us is read-only outside of library.c context.
Note that this commit reverts previous one (rB6b1d77a8052b) - please **do not** backport this one in 2.77.
Similar cause as in T47482, we used to have poor handling of 'user_one' cases of ID usage,
leading to inconsistent behavior depending on order of operations e.g.
Here, was object used by a group but not linked in any scene - once linked in scene,
their usercount would be 2, leading to 'making single copy', when it's actually not needed.
We now have better control here, so let's use it!
Note that other ID 'make single user' code will likely need similar fix (Images, etc.).
Safe to be backported to 2.77.
In response to user feedback, this commit brings back the ability to
limit motionpath clearing to only happening for those on selected
objects/bones.
By default, the "Clear" operator will clear from all objects/bones,
unless the Shift key is held.
Also re-reported through IRC by Thomas Beck (@plasmasolutions), thanks.
Though it's not ideal in theory, we have quite poor handling of object datablock currently
from user PoV - before this commit, it was not easily possible to get fully rid of an object
anymore if you did not removed it from all its groups before deleting it.
So for now, restore 2.76 behavior (namely, unlink an object from avaerything in Blender
once it is no more used by any scene).
Better handling of all this is TODO for later (also related to much more heavy changes
done in id-remap branch regarding sanitizing our ID deletion process).
BKE_main_id_tag_/BKE_main_id_flag_ were horrible naming now that we split those
into flags (for presistent one) and tags (for runtime ones).
Got rid of previous 'tag_' functions behavior (those who were dedicated shortcuts
to set/clear LIB_TAG_DOIT), so now '_tag_' functions affect tags, and '_flag_'
functions affect flags.
Corrects mirror syncing for invert, levels & smooth.
Note that the code changed to process mirroring even if both verts are selected,
since group flipping can mean that is still meaningful.
