This patch removes unnecessary calls to `BKE_main_id_tag_all` where the
same job is done by `BKE_main_id_clear_newpoins` on the following line.
Reviewed By: campbellbarton, mont29
Ref D11379
Sharing data between duplicated IDs should be restricted to depsgraph
(CoW) cases, not all NO_MAIN ones...
While this was probably not an issue currently, we aim at using more and
more out-of-main IDs for temp data processing.
NOTE: Somewhat related to T88555, and similar issue as the one fixed in
rBdfb963c70df5.
Previously, the "follow path constraint" and "follow parented curve"
were clamped. This restriction was lifted in rBcf2baa585cc8
Add back an option to get the old behavior in the "Path animation" settings.
Reviewed By: Sybren
Differential Revision: http://developer.blender.org/D11263
Resolve ownership ambiguity with shared physics pointers.
Previously, LIB_ID_CREATE_NO_MAIN allowed pointer sharing with
the source ID so physics caches can be shared between original and
evaluated data: (Object.soft.shared & Object.rigidbody_object.shared).
This only worked properly for LIB_TAG_COPIED_ON_WRITE ID's,
as LIB_TAG_NO_MAIN can be used in situations where the original ID's
lifetime limited by it's original data.
This commit adds `LIB_ID_COPY_SET_COPIED_ON_WRITE` so ID's only share
memory with original data for ID's evaluated in the depsgraph.
For all other uses, a full copy of physics data is made.
Ref D11228#287094
Rename BKE_object_runtime_free -> BKE_object_runtime_free_data,
since the runtime pointer is part of the object, only the data is freed.
Leave the data cleared to avoid accidental use,
this is in keeping with other `*_free_data()` functions.
While fa7ddd0f43 fixed the reported issue,
the possibility of reusing runtime data during curve-to-mesh conversion
remained. Instead of treating the bounding-box as a special case,
clear all run-time data for temporary objects.
Ref D11026
Reviewed By: sergey
This allows us to remove a callback from the modifier type info struct.
In the future the these modifiers might just be replaced by nodes
internally anyway, but in the meantime it's nice to unify the handling
of evaluated geometry a bit.
Differential Revision: https://developer.blender.org/D11080
`ob->runtime.geometry_set_eval` can contain instances as well.
This only affected instances generated by geometry nodes.
We should probably have a separate function that tells us if an object
has instances or not..
This introduces a context path to the spreadsheet editor, which contains
information about what data is shown in the spreadsheet. The context
path (breadcrumbs) can reference a specific node in a node group
hierarchy. During object evaluation, the geometry nodes modifier checks
what data is currently requested by visible spreadsheets and stores
the corresponding geometry sets separately for later access.
The context path can be updated by the user explicitely, by clicking
on the new icon in the header of nodes. Under some circumstances,
the context path is updated automatically based on Blender's context.
This patch also consolidates the "Node" and "Final" object evaluation
mode to just "Evaluated". Based on the current context path, either
the final geometry set of an object will be displayed, or the data at
a specific node.
The new preview icon in geometry nodes now behaves more like
a toggle. It can be clicked again to clear the context path in an
open spreadsheet editor.
Previously, only an object could be pinned in the spreadsheet editor.
Now it is possible to pin the entire context path. That allows two
different spreadsheets to display geometry data from two different
nodes.
The breadcrumbs in the spreadsheet header can be collapsed by
clicking on the arrow icons. It's not ideal but works well for now.
This might be changed again, if we get a data set region on the left.
Differential Revision: https://developer.blender.org/D10931
Previously, the spreadsheet editor could only show data of the original
and of the final evaluated object. Now it is possible to show the data
at some intermediate stages too.
For that the mode has to be set to "Node" in the spreadsheet editor.
Furthermore, the preview of a specific node has to be activated by
clicking the new icon in the header of geometry nodes.
The exact ui of this feature might be refined in upcoming commits.
It is already very useful for debugging node groups in it's current
state though.
Differential Revision: https://developer.blender.org/D10875
The issue was that where_on_path uses a resampled curve to get the data
from the curve. This leads to disconnects between the curve the user
sees and the evaluated location data.
To fix this we simply use the actual curve data the user can see.
The older code needed a cleanup either way as there were hacks in other
parts of the code trying to work around some brokenness. This is now
fixed and we no longer need to clamp the evaluation range to 0-1 or make
helper functions to make it do what we actually want.
Reviewed By: Campbell, Sybren
Differential Revision: http://developer.blender.org/D10898
Initially this is a typo when solving merge conflict back in 2017
in commit rBf4140f2c8138.
The code was so for 3 years, so it is safer to assume that this is
the new expected design. The affected codepath only comes from the
BKE_object_modifier_update_subframe() which is discouraged from use
and have other issues.
Eventually those offending codepaths will be removed completely.
The grade-schema for now is more localized: remove ID_RECALC_ALL
which seems to be misused and is causing issues like the ones which
are described and discussed in T81340.
On user level there should be no measurable changes. In fact, no
functional changes at all are expected to happen.
Reviewed By: sybren
Differential Revision: https://developer.blender.org/D9220
Fix the data management bug where evaluation of lattice objects would
write back to the CoW copy of the Lattice ID, even when that copy was
shared between objects.
Each lattice object evaluation now stores its own evaluated data copy
via `BKE_object_eval_assign_data()`.
Reviewed By: sergey
Maniphest Tasks: T78650
Differential Revision: https://developer.blender.org/D10790
Linked data should only be duplicated if relevant `eDupli_ID_Flags` flag
is set (`USER_DUP_LINKED_ID`), this is being taken care of by generic
`BKE_id_copy_for_duplicate` function, but for some reasons (?)
`BKE_object_duplicate` was directly using `BKE_id_copy` for itself...
Note that this had especially bad consequences when duplicating
overrides of collections...
In this case both the mirror object and object itself moving in time may
change the geometry and must be checked.
Differential Revision: https://developer.blender.org/D10757
This concerns currently only collections (`master_collection` of scenes)
and root node trees. It removes the matching type-specific helpers
(`BKE_collection_master_scene_search` and `BKE_node_tree_find_owner_ID`).
No functional change expected here.
NOTE: Current implementation of `owner_get` is far from optimal, we
could probably do it better, see {T69169}.
NOTE: While it could also have it, shapekeys IDTypeInfo was left out of
this change for now. Mainly because it sould not be used currently, and
we ultimately want to demote shape keys from ID status anyway.
This patch adds a to_curve method to the Object ID. This method is
analogous to the to_mesh method. The method can operate on curve and
text objects. For text objects, the text is converted into a 3D Curve ID
and that curve is returned. For curve objects, if apply_modifiers is
true, the spline deform modifiers will be applied and a Curve ID with
the result will be returned, otherwise a copy of the curve will be
returned.
The goal of this addition is to allow the developer to access the splines
of text objects and to get the result of modifier applications which was
otherwise not possible.
Reviewed By: Brecht
Differential Revision: https://developer.blender.org/D10354
Currently this is needed to properly tag PointCache's for info update
(fixes an issue reported in T82503).
Suspect we may need this in more cases in the future though, RNA
assign/update processes are not always 100% enough to deal with
complicated corner cases.
Things like pointers to particle systems, or softbody data being stored
outside of its modifier, make it impossible for internal modifier copy
data code to be self-contained currently. It requires extra processing.
In existing code this was handled in several different places, in
several ways, and alltogether fairly inconsistently. Some cases were
even not properly handled, causing e.g. crashes as in T82945.
This commit addresses those issues by:
* Adding comments about the hackish/unsafe parts `psys` implies when
copying some modifier data (since we need to ensure particle system
copying and remapping of those pointers separately).
* Adding as-best-as-possible handling of those cases to
`BKE_object_copy_modifier` (note that it remains fragile, but is
expected to behave 'good enough' in any practical usecase).
* Remove special handling for specific editor code
(`copy_or_reuse_particle_system`). This should never have been
accepted in ED code area, and is now handled by
`BKE_object_copy_modifier`.
* Factorize copying of the whole modifier stack into new
`BKE_object_modifier_stack_copy`, now used by both `object_copy_data`
and `BKE_object_link_modifiers`.
Note that this implies that `BKE_object_copy_modifier` and
`BKE_object_copy_gpencil_modifier` are now to be used exclusively to
copy single modifiers. Full modifier stack copy should always use
`BKE_object_modifier_stack_copy` instead.
Fix T82945: Crash when dragging modifiers in Outliner.
Maniphest Tasks: T82945
Differential Revision: https://developer.blender.org/D10148
Things like pointers to particle systems, or softbody data being stored
outside of its modifier, make it impossible for internal modifier copy
data code to be self-contained currently. It requires extra processing.
In existing code this was handled in several different places, in
several ways, and alltogether fairly inconsistently. Some cases were
even not properly handled, causing e.g. crashes as in T82945.
This commit addresses those issues by:
* Adding comments about the hackish/unsafe parts `psys` implies when
copying some modifier data (since we need to ensure particle system
copying and remapping of those pointers separately).
* Adding as-best-as-possible handling of those cases to
`BKE_object_copy_modifier` (note that it remains fragile, but is
expected to behave 'good enough' in any practical usecase).
* Remove special handling for specific editor code
(`copy_or_reuse_particle_system`). This should never have been
accepted in ED code area, and is now handled by
`BKE_object_copy_modifier`.
* Factorize copying of the whole modifier stack into new
`BKE_object_modifier_stack_copy`, now used by both `object_copy_data`
and `BKE_object_link_modifiers`.
Note that this implies that `BKE_object_copy_modifier` and
`BKE_object_copy_gpencil_modifier` are now to be used exclusively to
copy single modifiers. Full modifier stack copy should always use
`BKE_object_modifier_stack_copy` instead.
Fix T82945: Crash when dragging modifiers in Outliner.
Maniphest Tasks: T82945
Differential Revision: https://developer.blender.org/D10148
These two operators (one for grease pencil, one for other objects)
copy a single modifier from the active object to all selected objects.
The operators are exposed in the dropdown menus in modifier headers.
Note that It's currently possible to drag and drop modifiers between
objects in the outliner, but that only works for dragging to one object
at a time. Modifiers can also be copied with the "Make Links" operator,
but that copies *all* modifiers rather than just one. The placement
and scope of these new operators allow for more useful poll messages
and error messages as well.
Every object type that supports modifiers is supported. Although hook
and collision modifiers aren't supported because of an unexplained
comment in `BKE_object_copy_modifier`, other than that, every modifier
type is supported, including particle systems, nodes modifiers, etc.
The new modifiers are set active, which required two small tweaks to
`object.c` and `particle.c`.
Reviewed By: Hans Goudey (with additional edits)
Differential Revision: https://developer.blender.org/D9537
Always assume geometry nodes produce potentially animated meshes or point
clouds. In general it is hard to check if geometry nodes are animated, and
for modifiers this was already weak.
The better solution will likely involving checking which geometry was
modified by the depsgraph on frame change, to replace the current mechanism
of manually checking for certain types of modifiers and animation.
Remove DNA headers, using forward declarations where possible.
Also removed duplicate header, header including it's self
and unnecessary inclusion of libc system headers from BKE header.
Object previews are really helpful for visual data-block selection, like asset
browsing. Having them be generative should also be quite handy and should work
well enough in many, if not most cases.
What this does is simple:
* Place the object (actually a deep copy of it, for thread safety) in a virtual
.blend into an empty scene/view-layer.
* Add a camera, point it towards the front of the object, assuming that means
pointing towards its +Y axis.
* Use "Camera Fit Frame to Selected" logic to put the object into frame.
* Create a threaded off-screen render.
Of course, such an automatic preview will not work in all situations. E.g. it
currently does a bad job capturing a single plane. We could add options for
more advanced automatic previews, but probably custom previews is more
important, which I committed already (812ea91842).
Part of the first Asset Browser milestone. Check the #asset_browser_milestone_1
project milestone on developer.blender.org.
Reviewed as part of https://developer.blender.org/D9719.
Reviewed by: Bastien Montagne, Brecht Van Lommel
Since the initial merge of the geometry nodes project, the modifyPointCloud
function already was already modifying a geometry set. The function wasn't
renamed back then, because then the merge would have touched many
more files.
Ref T83357.
This commit adds functions to set and get the object's active
modifier, which is stored as a flag in the ModifierData struct,
similar to constraints. This will be used to set the context in
the node editor. There are no visible changes in this commit.
Similar to how the node editor context works for materials, this commit
makes the node group displayed in the node editor depend on the active
object and its active modifier. To keep the node group from changing,
just pin the node group in the header.
* Shortcuts performed while there is an active modifier will affect
only that modifier (the exception is the A to expand the modifiers).
* Clicking anywhere on the empty space in a modifier's panel will make it active.
These changes require some refactoring of object modifier code. First
is splitting up the modifier property invoke callback, which now needs
to be able to get the active modifier separately from the hovered
modifier for the different operators.
Second is a change to removing modifiers, where there is now a separate
function to remove a modifier from an object's list, in order to handle
changing the active.
Finally, the panel handler needs a small tweak so that this "click in panel"
event can be handled afterwards.
This is the initial merge from the geometry-nodes branch.
Nodes:
* Attribute Math
* Boolean
* Edge Split
* Float Compare
* Object Info
* Point Distribute
* Point Instance
* Random Attribute
* Random Float
* Subdivision Surface
* Transform
* Triangulate
It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier.
Notes on the Generic attribute access API
The API adds an indirection for attribute access. That has the following benefits:
* Most code does not have to care about how an attribute is stored internally.
This is mainly necessary, because we have to deal with "legacy" attributes
such as vertex weights and attributes that are embedded into other structs
such as vertex positions.
* When reading from an attribute, we generally don't care what domain the
attribute is stored on. So we want to abstract away the interpolation that
that adapts attributes from one domain to another domain (this is not
actually implemented yet).
Other possible improvements for later iterations include:
* Actually implement interpolation between domains.
* Don't use inheritance for the different attribute types. A single class for read
access and one for write access might be enough, because we know all the ways
in which attributes are stored internally. We don't want more different internal
structures in the future. On the contrary, ideally we can consolidate the different
storage formats in the future to reduce the need for this indirection.
* Remove the need for heap allocations when creating attribute accessors.
It includes commits from:
* Dalai Felinto
* Hans Goudey
* Jacques Lucke
* Léo Depoix
Avoid the evaluation of constraints when computing the parent-inverse
matrix.
Constraints are meant to be evaluated last; object transforms are
computed this order:
1. `parent->obmat` (the parent object's world matrix)
2. `ob->parentinv` (the object's parent-inverse matrix)
3. Object's loc/rot/scale
4. Object's constraint evaluation
When the constraints are used to compute the parent-inverse matrix,
their effect is moved from step 4 to step 2 in this list, potentially
rotating or scaling the object's local transform. This causes unwanted
movement as reported in T82156.
Reviewed By: looch
Differential Revision: https://developer.blender.org/D9413
Root of the issue is that point caches are added to the object's list
on-demand, which often ends up with them being added only during
depsgraph evaluation, i.e. on COW objects.
This could result in having 'orig' data caches with invalid/unset stack
index at some points (e.g. when reading a file and applying
liboverrides), leading to discarding valid existing disk cache files.
Fact that one of those index is signed, and the other not, does not
help...
While this is very weak, fixing broken PointCache code is out of the
scope of a bug fix, so this patch merely:
* Simplifies and factorizes the code generating the 'extension' part of
caches filenames;
* Ensures `BKE_object_insert_ptcache` is called when needed so that we
always have a valid stack index to generate that filename extension.
This is only a bandaid, but it is simple and should be safe enough for
now.
Related to T82503.
