Copying scenes didn't handle rigid body worlds previously.
Since we use groups to keep track of objecs in the rigid body sim it's
tricky to do the right thing here since groups aren't duplicated.
One option would be to create new groups and add the duplicated objects
into those but that has other drawbacks.
So the rigid body world isn't copied for now.
TODO find a better way of handling this.
Since rigid bodies need their world to be be updated correctly we now
pass it alongside the parent scene in scene_update_tagged_recursive().
Add BKE_object_handle_update_ex() as well as other object functions
that take a RigidBodyWorld for this.
Ideally this shouldn't be needed but we'd have to restructure scene
handling for that. It's not a small taks however and definitely not
something that can be done before release.
Thanks to Campbell for review.
This was caused by multiple instantiations of the same basic problem. The
rigidbody handling code often assumed that "scene" pointers referred to the
scene where an object participating in the sim resided (and where the rigidbody
world for that sim lived). However, when dealing with background sets, "scene"
often only refers to the active scene, and not the set that the object actually
came from. Hence, the rigidbody code would often (wrongly) conclude that there
was nothing to do.
For example, we may have the following backgound set/scene chaining scenario:
"active" <-- ... <-- set i (rigidbody objects live here) <-- ... <-- set n
The fix here is a multi-part fix:
1) Moved sim-world calculation from BKE_scene_update_newframe() to
scene_update_tagged_recursive()
+ This is currently the only way that rigidbody sims in background sets will
get calculated, as part of the recursion
- These checks will get run on each update. <--- FIXME!!!
2) Tweaked depsgraph code so that when checking if there are any time-dependent
features on objects to tag for updating, the checking is done relative to the
scene that the object actually resides in (and not the active scene). Otherwise,
even if we recalculate the sim, the affected objects won't get tagged for
updating. This tagging is needed to actually flush the transforms out of the
RigidBodyObject structs (written by the sim/cache) and into the Object
transforms (obmat's)
3) Removed the requirement for rigidbody world to actually exist before we can
flush rigidbody transforms. In many cases, it should be sufficient to assume
that because the object with rigidbody data attached has been tagged for
updates, it should have updates to perform. Of course, we still check on this
data if we've got it, but that's only if the sim is in the active scene.
- TODO: if we have further problems, we should investigate passing the
"actual" scene down alongside the "active" scene for BKE_object_handle_update().
Now we do simple triangulation and calculate signed area of triangles to
account for concave polygons.
This only works correct for planar polygons but gives better results
overall.
Error since July 2005, when DerivedMesh was introduced.
Vertex and Face duplicators now work for all modifiers. (not only deformers).
For example mirror and array modifier didn't work.
This will preserve constraint <-> rigid body realationships so
constraint setups aren't broken after duplication.
Based on a patch by Brandon Hechinger (jaggz), thanks.
The use alpha option moved from the texture datablock to the image, and now it
will duplicate the image datablock in case you have one texture using alpha and
the other not.
Linked Armature with local proxy, using feature "Custom shape at other bone" stopped working
on undo/redo.
It was actually a bug in the original commit (r26600, april 2010), storing a pointer from
the library bone into the local proxy bone.
That's strictly forbidden in Blender, but it never showed up because on every undo-redo a
complete proxy-sync was called again. To allow undo/redo I had to disable this syncing,
except for file load. Hence the feature got lost :)
The fix is simple; just store the pointer to its own local bone instead.
Issue was caused by couple of circumstances:
- Normal Map node requires tesselated faces to compute tangent space
- All temporary meshes needed for Cycles export were adding to G.main
- Undo pushes would temporary set meshes tessfaces to NULL
- Moving node will cause undo push and tree re-evaluate fr preview
All this leads to threading conflict between preview render and undo
system.
Solved it in way that all temporary meshes are adding to that exact
Main which was passed to Cycles via BlendData. This required couple
of mechanic changes like adding extra parameter to *_add() functions
and adding some *_ex() functions to make it possible RNA adds objects
to Main passed to new() RNA function.
This was tricky to pass Main to RNA function and IMO that's not so
nice to pass main to function, so ended up with such decision:
- Object.to_mesh() will add temp mesh to G.main
- Added Main.meshes.new_from_object() which does the same as to_mesh,
but adds temporary mesh to specified Main.
So now all temporary meshes needed for preview render would be added
to preview_main which does not conflict with undo pushes.
Viewport render shall not be an issue because object sync happens from
main thread in this case.
It could be some issues with final render, but that's not so much
likely to happen, so shall be fine.
Thanks to Brecht for review!
It's only needed when they're being transformed.
Also deactivate passive objects after transformation so they don't keep
acitvating deactivated objects.
Fixes issues with using "start deactivated".
This modules does not depend on any blender-specific data
structures or algorithms and due to our policy better be
placed to intern/
Shall be no functional changes, tested CMake and SCons on
Linux, hopefully other platforms will work as well.
P.S. SVN history shall be preserved for the files.
This means you can for example, uv unwrap in quad-view and change settings in the toolbar without defaulting back to the first quad-view region available.
This may be displayed to the user later, for now this is set on executing registrable operators.
Issue was caused by storing BB calculated from final displist in
Curve datablock and not having Object's BB at all. This is not
clear at how could have been worked for so long.
Changed it so Curve's BB is calculated from non-deformed displist,
which matches BKE_object_min_max and BKE_curve_texspace_calc and
made it so Object's BB would be calculated from final displist.
