* Ensure that when new constraints are created, the new settings have sensible
default values.
TODO: we need to version-patch old files
* Fix problem with variable shadowing (which wasn't causing problems AFAIK)
From the looks of things, this was a typo. The result was that if you had a bone
with the minimum volume restriction in place, the bone would not get any thinner
when it was stretched out.
This commit adds a new type of volume preservation mode to Spline IK
which makes it possible to set limits on the minimum and maximum
scaling of bone "fatness".
* The old volume preseving mode has been kept but renamed, to avoid
breaking old rigs. "Volume Presevation" uses the new method, while
"Inverse Preservation" is the old one.
* The code and settings for this new xz scale mode are directly lifted
from the improved Stretch To constraint
Seems like a weird issue, but to sort panels "qsort" is used, which works slightly different on Windows. So all I had
to do was cleaning up the logic in find_highest_panel so that headerless panels are sorted, but that it absolutly not
allows headerless panels to be above normal panels.
I made sure it works fine on Linux as well.
There was a hard-coded check to exit the fileselector when restoring a view.
Now, when space types differ, flag areas as temporary and switch back to the previous type only in this case.
This means you can select a file while having a file-selector space type open, and not loose it every time.
This time, it's a dedicated operator user has to run before saving the file.
And it recursively check all IDs linked from each scene, therefore rendering
materials etc. previews using a scene they are used in.
Note the renderengine issue is not completely addressed this way
(existing code for icon previews seems to ignore completely other engines,
and IDs not linked anywhere (fake-user ones) will be rendered with current scene's engine
as fallback, also you can get a material linked to an hidden object in a scene, etc.).
Reviewers: sergey, campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D980
Issue was, in case of using such stack within a structure, the '_' underscore
would be added in front of struct variable
(e.g. `my_struct.my_stack` would lead to (try to) using `_my_struct.my_var_pool` ...).
Now underscore is appended to var names, ugly but working.
Note did not touch to the alloca variants of those macros, since in this case enforcing
a pure local use is best I think.
Happens because material setting now occurs in the derived mesh drawing
routine as it should. However that means that it also happens during
selection and that influenced the drawing state somehow.
In 2.72 this did not occur because material setting happened during draw
setting (skip or draw) instead of after the draw setting passed (so
selection would skip it by use another draw setting function). Of course
this violated design but worked.
Made it now so backbuffer selection does not enable materials (it's
redundant in those cases anyway).
This could be ported to a possible 'a' release but as is classic with
display code there may be some other places that it could backfire.
Tested fix with texture/vertex painting and selection which use
backbuffer for both subsurf and regular meshes and it seems to work OK.
We can now use 'generic' data transfer instead.
Note new one is not an exact replacement, it should be able to do
everyting old op could do though, and more.
Needed to replace weight transfer modifier in WeightPaint mode...
Note this is not exposed to users in UI, shall remain technical intern
parameter imho. Esp. since behavior when several sources is a bit 'random'
(merely uses each source in selection order...).
Also, this correct a bug, where 'lib' linked objects/meshes could not be used
as source...
Own fault in rBb154aa8c060a60d to fix T42447... Reverted that commit, and added
kind of not-so-nice hack instead.
Note root of the issue comes from the special case we are doing here re 'Local'
space of parent-less objects. In that case, local space should be the same as
world one, but instead we apply the object rotation to it... This is inconsistent
with all other cases and could very well lead to other issues as T42447, but afraid
fixing that properly would be rather hairy - not to mention it would likely break
all existing riggings etc. :(
Should be safe for a 2.73a, shall we need it.
Not much to add, modifier uses same code as operator basically, only key difference
is that modifier will never create data layers itself, you have to use dedicated operator
for that.
This add code needed to map a CD data layout from source mesh towards destination one,
and code needed to actually transfer data, using BKE's mesh remap generated data.
This allows to transfer most CD layers (vgroups, vcols, uvs...) as well as fake, boolean ones
(like smooth/sharp edges/faces, etc.). Some types are not yet transferable, mainly
shape keys, this is known TODO.
Data transfer can also use some advanced mixing in some cases (mostly, vgroups and vcols).
Notes:
* New transfer operators transfer data from active object towards selected ones.
* Modifier will be committed separately.
* Old weight transfer code (for vgroups) is kept for now, mostly because it is the only
usable one in weightpaint mode (it transfers from selected object to active one,
this is not sensible in Object mode, but needed in WeightPaint one). This will be addressed soon.
Again, heavily reviewed and enhanced by Campbell, thanks!
This is the (big!) core of mesh transfer data, it defines a set of structures
to represent a mapping of mesh elements (verts, edges, polys of loops) between
two arbitrary meshes, and code to compute such mappings.
No similarity is required between source and destination meshes (though results
when using complete different meshes are rather unlikely to be useful!).
This code is not bound to data transfer, it is defined to be as generic as possible,
and easy to reuse or extend as needs arise.
Several methods of mapping generation are defined for each element type,
we probably will have to adjust that in future (remove useless ones, add
new ones...).
For loops, you can also define islands (for UVs e.g.) so that loops of a same
destination polygon do not 'spread' across several source islands.
Heavily reviewed and enhanced by Campbell, thanks a lot!
`INSERT_FAST` implies you call `calchandles_fcurve()` at the end...
For now, since we do not store edited FCurves nor can we get them easily
(requires RNA...), just update handles of all fcurves, it's much more
performant than removing usage of `INSERT_FAST` anyway.
You can now use lower-level '_ex' versions of bvh creators to only use part of
the mesh's elements in the BVH, and/or create bvh from non-DM sources.
Needed for transfer data.
Note edges extend version of bvh creator is not added here, not needed so far.
and graph editor.
This was a tricky commit that was not so straightforward to make work.
The information for bones is not easy to come by in the animation curves,
however we do have some string manipulation tricks to make it happen.
Testing in gooseberry worked for the rigs there, commiting to master now
Propper fix reverting most of rB60e70c0c6014e5, which was only partial specific fix.
This code uses generic `BKE_id_lib_local_paths()` func to handle all possible paths.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D977
Also cleanup extrude code.
- remove normal calculation.
- remove return values for transform type.
- use enums.
Thanks to Psy-fi for finding the initial fix.
Simply have to rebase onto main filepath when copying, if source datablock is lib and path is relative.
Afaict, only affected Image and Text datablocks. MovieClip would also be a candidate, but has
no copy implemented currently.
