This is in preparation of new object types. This only changes mesh_eval, we
may do the same for mesh_deform_eval and other areas in the future if there is
a need for it.
This previously caused a bug in T74283, that should be fixed now.
Differential Revision: https://developer.blender.org/D6695
This reverts commit f2b95b9eae.
Fix T74283: modifier display lost when moving object in edit mode.
The cause is not immediately obvious so better to revert and look at this
carefully.
This is in preparation of new object types. This only changes mesh_eval, we
may do the same for mesh_deform_eval and other areas in the future if there is
a need for it.
Differential Revision: https://developer.blender.org/D6695
Was crashing due to RBW mssing shared->physics_world [which can happen
when undoing the deletion of the last object in the world].
This can be gained back by BKE_rigidbody_validate_sim_world.
Reviewed By: mont29
Maniphest Tasks: T70667
Differential Revision: https://developer.blender.org/D6037
Fixing/working around another weakness of current RBW model... This is
not really nice, but it should work for now, and we cannot really do
anything else but that kind of monkey patching here anyway.
Side-reported in T70505.
Code did not ensure deleted object was removed from the RBW constraints
collection, leading to some invalid status (object in constraints
collection but without relevant contraints data).
Also fixed another issue - code deleting RBW objects would try to remove
any constraint one using it as target, in a very bad and broken way,
since you cannot iterate over objects of a collection while removing
some... Now instead just NULLify relevant pointers... I hope it works,
otherwise we'll have to take a different approach.
Needless to stress again how weak the whole RBW code is in general, and
regarding same object being used by RBW in more than one scene in particular,
that is known broken situation anyway.
We only had a very limited, specific handling of that in collection
duplication code, but this has to be handled at a much more general
level in Object copy code itself, since it makes no sense to duplicate
rigidbody object data without adding new copy to relevant rigidbody
collections...
WARNING: This is a fairly risky rework of rigidbody handling logic
when copying an Object data-block. It is *NOT* considered safe enough
for 2.80 release.
I tried to take into account copy flags to not mess with other IDs
(collections) when we are copying outside of Main, and also not do deg
tags when this is forbidden, but risk of something going wrong here is
too high...
Previously settings were removed, now add to the rigid body world automatically
even if it's a bit ill defined, since this is confusing for users.
Fundamentally the concept of a rigid body world collection could be revised, and
left only as an optional thing.
While user should never do that, it appears many end up using a 'view
layer' instancing collection as RBW collection, and even worse, have
objects in that unique collection.
Therefore, when removing RB simulation from an object, which among other
things has to remove it from the RBW collection, it would fully delete
the object from the blend file.
This fix merely checks the usercount of RB-removed object, and if it is
at 1 (which means object was in a single collection), it adds it to the
scene's master collection first.
Convention was not to but after discussion on 918941483f we agree its
best to change the convention.
Names now mostly follow RNA.
Some exceptions:
- Use 'nodetrees' instead of 'nodegroups'
since the struct is called NodeTree.
- Use 'gpencils' instead of 'grease_pencil'
since 'gpencil' is a common abbreviation in the C code.
Other exceptions:
- Leave 'wm' as it's a list of one.
- Leave 'ipo' as is for versioning.
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
This removes a bunch of animation/driver evaluations and recalc flags that
should be redundant in the new depsgraph, and were incorrectly affecting
the evaluated scene in a permanent way.
Still two cases that could be removed if the depsgraph is improved, in
BKE_object_handle_data_update and BKE_cachefile_update_frame.
For physics subframe interpolation there are also still calls to
BKE_object_where_is_calc that should ideally be removed as well, though
they are not known to cause keyframing bugs.
Differential Revision: https://developer.blender.org/D4274
We cannot let those data be generated on-the-fly in RBW evaluation
anymore, since those would be added to CoW eval object and never ported
back to orig objects.
We *could* get orig objects in eval code, of course, but as in
constratints, this is not really threadsafe and future proof, depsgraph
evaluation should really write back to orig data as little as possible.
So instead, add code to ensure required data is generated to objects
when their collection is added to rigidbody world.
Note that we *may* want to clean that up once collection is no more used
by RB? On the other hand, people might want to keep those data around to
be able to switch between different setups easily... So think it's OK to
keep them at least for now.
The old springs with damping 1.0 operate in a special way that
is more similar to plastic deformation than a spring. Some users
rely on that, so let the user choose which implementation to use.
This also restores full backward compatibility with 2.79.
Reviewers: sergof
Differential Revision: https://developer.blender.org/D3544
To prevent the pointcache from being copied-on-write too (and requiring
copying back), the cache is now shared between the original and
evaluated scenes. Reading from the cache is always allowed; running the
sim and writing to the cache is only allowed when the depsgraph is
active.
Some pointers have moved from RigidBodyWorld (RBO) to
RigidBodyWorldShared (RBOS). writefile.c copies some pointers back from
RBOS to RBO so that the file can still be opened on older Blenders
without crashing on a segfault.
The RigidBodyWorldShared struct is written to the blend file, because it
refers to the PointCache ID block.
The RigidObjectShared struct is runtime-only, and thus not saved to the
blend file.
An RNA getter-function is used to hide the new 'shared' pointer. As a
result the Python API hasn't changed.
Reviewed by: campbellbarton
Differential Revision: https://developer.blender.org/D3508
