- Use the active group of the active (target) object (not the active group of the other, unselected object)
- Ensure the active group doesnt change from the one that was set originally.
- defgroup_find_name was doing redundant lookup on its self.
move only the origin and not the bone. It doesn't need to use any object
matrices to add the bone, the only reason this worked before is because they
were still unit matrices due to depsgraph not running immediately on add.
with other applications launching SDL applications from Blender.
At the time this was added the game engine joystick code was unnecessarily
initializing the SDL video subsystem, and looking at the SDL source code that's
the only place this environment variable is read. That doesn't happen anymore,
though we do have WITH_GHOST_SDL now. But the environment variable is set after
GHOST has been initialized, otherwise this code would have actually broken that.
This is not the nicest behaviour but trying to keep both bullet and
blender side objects in sync breaks in this case.
There might be a better soluion but this avoids crashes for now.
Fixes: [#35995] Delete crash on specific scene (Physics)
the report explains the issue in detail, but basically you couldn't know if a mesh was in editmode without checking all the objects that use it.
add `is_editmode` readonly property for all datatypes which support editmode.
also make rna fail to build on implicit function declarations.
- poll function now checks for a mesh.
- other selected lattices would crash, check for meshes there too.
- better reporting when transfer fails.
- remove feature to sync with active bone after transfer, other tools don't do this (we could make into a generic function if its needed).
Now modifier stack wouldn't modify original curve's nurbs
and will operate on a copy of nurbs.
This makes it possible to process curve object update with
shared curve datablocks from multiple threads. There's no
big overhead for creating a copy of nurbs comparing to old
behavior which was allocating original vertex array and
apply coordinates on curve after all modifier are applied.
The only remained issue with curves is curve's bounding box
and texture space. It's not thread-safe, but it wouldn't
lead to crashes -- it just could lead to either memory
leak or wrong texture coordinates due to difference in
modifiers stacks of objects which shares the same curve.
DAG node already has got type field, so we could just check whether
type is ID_OB to distinguish whether object_handle_update need to
be called for node->ob.
This saves iterating via scene's bases when preparing threaded
update. This also will very much likely update objects which are
not in the scene base are used in dupli groups.
So now objects form dupli_groups are likely already properly updated
white traversing the DAG with threaded update and special hacks
are needed from main thread to update objects from dupli_groups
which was added in previous commit.
However, kept this hack for a while, need some more thoughts
and investigation.
Dupli-groups used to have special case for updating
which is BKE_group_handle_recalc_and_update. This
function calls BKE_object_handle_update for every
object in the group.
This isn't thread-safe, because object could be
updating in separate thread already. And what's
worse dependencies are not known for objects inside
the group, which makes it impossible to schedule
objects from the group in a safe way.
It's even impossible to schedule groups as different
tasks, because groups could share the same objects.
For now used simple but robust solution which is
updating dupli-groups in main thread, handling
groups one-by-one and updating objects from the
group one-by-one as well.
Will work on a proper solution for this later.
I know this is not so much nice to have this guys hanging
around in a general Object datablock and ideally they better
be wrapped around into a structure like DerivedMesh or
something like this. But this is pure runtime only stuff and
we could re-wrap them around later.
Main purpose of this is making curves more thread safe,
so no separate threads will ever start freeing the same path
or the same bevel list.
It also makes sense because path and bevel shall include
deformation coming from modifiers which are applying on
pre-tesselation point and different objects could have
different set of modifiers. This used to be really confusing
in the past and now dtaa which depends on object is stored
in an object, making things clear for understanding even.
This doesn't make curve code fully thread-safe due to
pre-tesselation modifiers still modifies actual nurbs and
lock is still needed in makeDispListsCurveTypes, but this
change makes usage of paths safe for threading.
Once modifiers will stop modifying actual nurbs, curves
will be fully safe for threading.
