The reason was the datablock is changed but it was not tagged for depsgraph refresh.
In some cases it could be possible to tag several times the same datablock, but as this is not the case all the times and the number of tags is always very small, it doesn't worth a complex code to keep a memory list of the datablocks to tag.
This removes G_FILE_HISTORY, G_FILE_SAVE_COPY & G_FILE_USERPREFS.
Using file-flags made logic harder to follow since it's not so clear
which flags are expected to be in G.fileflags & which are meant to be
set and passed as arguments, these are shared between read & write
functions too.
Add BlendFileWriteParams so options which don't need to be stored
aren't mixed up with flags that are stored for reuse.
By using own path construction instead of handy printf-like functions,
we get a 10% improvement on overall diffing process!
This remains way to slow on some complex production characters, but
always good to have still.
Use a median center of polygons as an initial value for volume center
calculation since the volume accumulation quickly generates very large
numbers that become inaccurate if the geometry is too far
from it's current center.
When "Relative Remap" option was added, the intention was only to remap
paths that were already relative. However it remapped all paths.
This was reported as T62612 and fixed recently,
however some Python script authors depended on the old behavior.
For users, it's reasonable to use the existing operators to make paths
absolute/relative. For scripts however it's useful to be able to write
out individual data-blocks with the ability to make all paths relative.
Now `bpy.data.libraries.write()` takes a path_remap argument which can
be `NONE/RELATIVE/RELATIVE_ALL/ABSOLUTE` allowing the script author to
choose how paths are handled when writing out data-blocks.
Addresses T77768.
Remove goto statement from `seq_render_image_strip()` and `seq_render_movie_strip()`.
`seq_render_image_strip_view()` and `seq_render_movie_strip_view()` is used to render individual views in both monoview and multiview branch.
I have included `seq_can_use_proxy()` for convinience
Reviewed By: sybren
Differential Revision: https://developer.blender.org/D7870
Partialy fixes T73828
Currently all 3 effect inputs were assigned even if not all 3 were used.
This causes problems with reassigning effects in python, because 3rd input is
not accessible.
This patch will only assign inputs that are necessary for effect to work
properly.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D6868
Now that we have a uniform consistent behavior in all our ID duplicate
funtions, we can easily factorize it greatly. Code gets cleaner,
smaller, and less error-prone.
Note that ultimately, this duplicate/deep copy behavior could be added
as a callback of IDTypeInfo.
We could also rethink the duplicate flags (some data, even some obdata,
like Lattice, are not coverred currently).
And so on. But at least code should now be much more easily maintainable
and extendable.
Previously, object (and sub-data) actions would be controlled by the
user preferences flag, collections actions would never be duplicted, and
scenes actions were always duplicated...
Now they all follow the user preferences settings.
Main change from user side, besides that all pointers should now be
properly remapped to new IDs, is that linked objects are no longer
preserved when doing a full copy of scenes.
Will open a task to check whether we actually still want that behavior
(and re-code it in a more correct way then).
This is the main part of work done here, it aims at uniformizing and
sanitizing that 'deep copy' process for supported IDs (currently scenes,
collections and objects).
Note that there will be more follow up commits after that one, but this
should be the most risky and changing one.
Using enum type itself in implementations, and uint in headers (as using
enums types in headers is a pain when enum are not defined and used in a
single same header file...).
It makes no sense to deep-copy a collection and not also copy its
children collections... Parameter was not used anymore anyway.
So now this duplicate function will always at least deep-duplicate all
of its children collections, recursively.
We want to get rid of those for all ID types ultimately, but that one
was only used in one place, being the only one calling
`BKE_collection_duplicate` without hierarchical duplicate and parent
collection pointer, effectively using the full power of the complex deep
duplication code for a mere `BKE_id_copy` call...
This will allow for further cleanup in duplicate code.
This patch adds two options:
- Convert a mesh to grease pencil strokes.
- Bake the mesh animation into grease pencil strokes.
Both are related and must be included in the same patch.
Related to tasks: T77629 and T77630
Notice: The conversion is done for mesh edges and it's not considering any visibility clipping. All edges are exported, no matters if it's visible or not.
Example of Convert a Mesh to Grease Pencil strokes:
{F8606028}
This conversion was inspired by the technique used by @luamono in this tweet: https://twitter.com/luamono/status/1239983662176841730
Example of Bake Animation (the video is a little outdate, but the basic functionality is the same, only small changes in UI):
{F8606032}
Reviewed By: mendio, pepeland
Maniphest Tasks: T77629, T77630
Differential Revision: https://developer.blender.org/D7983
Now that `BKE_main_collections_parent_relations_rebuild()` is called
from readfile code, we need to make it resilient to potential NULL
master collection pointer in scenes.
This is part of a greater blenloader decentralization effort (T76372).
For modifiers the goal is that fewer files have to be modified when
a new modifier is added.
This patch just adds the `blendWrite` and `blendRead` callbacks to
`ModifierTypeInfo` but does not change any other code yet. In the next
steps, modifier specific code will be moved from `writefile.c` and
`readfile.c` into their corresponding `MOD_*` files.
This is actually a nice issue due to too much optimization...
* Making an ID local just reuse the linked one whenever possible, instead of
actually making a copy of it.
* Therefore, the collection containing that ID is seen as unchanged, since
the pointer itself remained the same.
* But on undo step, there is no way to reuse that local object, which then
gets deleted, and linked one gets re-created - at a different address.
* Collection, however, since unchanged, is not updated at all and thus keeps
reference to the to-be-deleted local object, instead of the linked one.
* Issue gets even worse with viewlayers, this leads to the crash.
To address this, this patch adds a 'virtual' update flags that does nothing
in update case, but will ensure that the affected IDs using the one made local
are properly detected as changed across the relevant undo step.
Note that the recalc flags were chosen mostly for a logical reason, and also
because they are already properly dealt with and cleared by undo code,
so this looks like the optimal solution.
Reviewed By: brecht
Maniphest Tasks: T77774
Differential Revision: https://developer.blender.org/D8006
Previously, constraints were added multiple times from different
vertices. This adds a GSet to check that the same constraint is not
being added twice when iterating over the neighbors of two different
vertices.
Reviewed By: zeddb
Differential Revision: https://developer.blender.org/D8007
- BKE_lattice_deform_data_create was init_latt_deform.
- BKE_lattice_deform_data_destroy was end_latt_deform.
- BKE_lattice_deform_data_eval_co was calc_latt_deform.
This is an improvement over 2.7x which converted edit-mesh to mesh
(CDDM) for all 3 modifiers.
Overall this increases performance in edit-mode by around 15-20%.
Now all overrides are handled that way. Performances of the process look
decent enough, even with production characters...
If performance issues still arise, we'll investigate other solutions.
This should also make T73154 obsolete now.
When a fluid is put under influence of gravity or acceleration, it
forms an internal pressure gradient, which causes observable effects
like buoyancy. Since now cloth has support for simulating pressure
changes caused by fluid compression or expansion, it makes sense to
also support the effects of gravity.
This is intended for better simulation of objects filled or
surrounded by fluids, especially when constrained by collisions
or pinned vertices, and should result in more realistic shapes.
Obviously, this doesn't actually simulate fluid dynamics; instead
it is assumed that the fluid immediately adapts to changes in the
shape or acceleration of the object without friction or turbulence,
and instantly reaches a new static equilibrium.
Differential Revision: https://developer.blender.org/D6442
Prefer meaningful function names over redundant NULL arguments.
Also clarify variable names as it wasn't obvious the object-data
is part of the object target.
