This issue it totally related on issue with changing object datablock.
For curves it used to guess object type from curve datablock based on
count of control points in V direction.
This quess fails in case when SurfCircle datablock is trying to be reused
by another surface object or as another sample empty surface databouck used
to be treated as curve.
Store type in Curve when creating new Curve datablock which is used in
this object type quessing function.
Note: Previously saved files wouldn't change behavior at all.
Regression was introduced in svn rev40343. It was caused by re-creating
EditMesh structure which was needed to solve issues with parenting to
vertices after topology changes. This would also erase derivedMesh.
Problem reported now is caused by missing derivedMesh which is used
to solve parenting and apply inverted matrix on ob->parentin, so
parented object used to stay at exactly the same position it used to
stay before parenting.
Not very nice solving of this issue: re-create derivedMesh after
re-creating EditMesh when parenting. Nicer solution would require
bigger changes and probably ful lrefactor of this tools.
Constraint (bones case only for now). See [#29100] for some problematic test
cases
* It is no longer necessary to have to press "Clear Inverse" before doing "Set
Inverse" to get a reliable result. The calculation now calculates the pose with
the inverse cleared as it's "baseline" first now, which has the same result as
clearing the inverse manually first.
* Also, this commit trials a new method for computing inverses when there is
more than one constraint on the bone. Previously it just temporarily muted the
offending constraint, but kept all following constraints active, thus
potentially including their results in the inverse calculation. However, since
the inverse should only really care about what the stack looked like up to and
including when the constraint is applied, all constraints starting from this one
onwards are now disabled when calculating the inverse. PLEASE TEST!!! In the
few tests I've done, the effects appear minimal, but this may be quite an issue
in the wild
- went over every BM_SetIndex call and added comments about its use, if its setting dirty values or correct ones.
- replace loops over all elements _just_ to set index values, with a new function, BM_ElemIndex_Ensure(...), this will eventually only initialize values when they are dirty.
- use NULL rather then 0 for pointers
- use static functions where possible
- add own includes to ensure func's and their declarations don't get out of sync.
Issue was caused by how CCGDM handles ORIGINDEX cystom layer:
It runs cycle through all faces to fill origindex array on each
call of dm->getFaceDataArray(dm, CD_ORIGINDEX)
Solved issue by obtaining origindex array once on baker data initialization and
using this stored array when interpolating multires grid data.
* Made it impossible to try to calculate/create new motion paths lasting 0
frames (i.e. 250 to 250) since we cannot allocate a zero-length array for these.
Start frame can now be at most end-frame - 1, and end frame at least start frame
+ 1
* If an invalid configuration does occur, warnings/reports will now be issued in
response to this instead of silently failing (as per this bugreport).
