This report points out thet absolute shape keys are unusable.
The problem is there was no way to adjust the play time of a shape key (all absolte shape keys would start at frame zero with no way to change the speed).
Added an 'eval_time' property to the key block that works like the curve path evaluation time, so the time in the keyblock can be controlled.
can type in any value, and only when sliding the number value there is a limit.
It was already possible to assign any value to a socket with node linking, so
this shouldn't cause any new issues.
Also raised the limits on the math nodes, with a patch by Agustin Benavidez.
This fix adds a "ref_id" ID pointer to BKE_all_animdata_fix_paths_rename() & co, which is the ID against which prefix+oldName/NewName is "applied", currently only used for drivers' bones targets. Just pass NULL to get same behavior as previously. A bit annoying to make such a change for such a specific case, but there seems to be no other way to go... :/
Note about long lines: I did not touch to two pieces of code (because I don’t see any way to keep a nicely formated, compact code, with shorter lines):
* The node types definitions into rna_nodetree_types.h
* The vgroup name functions into rna_particle.c
Realize this is bcon3 but this is was very bad IMHO.
- button adjusting key block was in between 2 object settings - which is misleading/confusing.
- you needed to click through all shapes to check which was muted, currently you's assume 1.0 means the shape is enabled.
Reviewed by Tom Musgrove and myself.
From the patch description:
ValterVB on #blendercoders submitted a long list of missing tooltips in Blender, and I went through the list and added all I knew. After that I crowdsourced the rest by putting a spreadsheet on Google docs and having people fill in the missing ones that I didn't know. So if there's some weird tooltip in there that doesn't make sense, that's why.
Thanks to Wolter, spacetug and others on BlenderArtists for contributing tooltips.
This commit partially fixes the problems with Shapekeys from older
files, as seen from the Regression suite (relative.blend and
dolphin.blend in particular).
In older files, keyblock->slidermax was never truly set to 1.0 even
though the UI may have shown such a value (which was bizzarely being
sourced from somewhere else). Hence, after loading the files in 2.5,
the shapekeys wouldn't animate, as the value would get clamped between
0 and 0.
To fix this, I've added a version patch which corrects these
situations in old files, and I've adjusted the slider-RNA code so that
it is not possible to set up such clamping anymore.
TODO:
The fixes detailed here only make it possible for these files to work
again in 2.5. However, I haven't been able to find a way to get the
files to actually work in 2.5 without manually changing the active
shapekey (per object) after loading the files with these patches
applied. Possibly it's just some depsgraph magic needed, unless
there's still some other evil voodoo in the shapekey code
only tags the ID and does the actual flush/update delayed, before the next
redraw. For objects the update was already delayed, just flushing wasn't
yet.
This should help performance in python and animation editors, by making
calls to RNA property update quicker. Still need to add calls in a few
places where this was previously avoided due to bad performance.
to specify different spring lengths.
Implementation is quite ugly because the shape key has to be pulled
through the modifier stack somehow, need a more flexible data mask
system to solve this properly.
(commits 27773,27775,27778 by Brecht from render25 branch)
See the bugreport comments for full breakdown of the fix.
--
The change in brush.c is to get blender compiling again, after my previous commit which tried to fix a compiler warning related to this (but in the header file instead).
* Property update functions no longer get context, instead they get only
Main and Scene. The RNA api was intended to be as context-less as
possible, since it doesn't really matter who is changing the property,
everything that uses the property should be updated.
* There's still one exception case that use it now, screen operations
still depend on context too much. It also revealed a few places using
context where they shouldn't.
* Ideally Scene shouldn't be passed, but much of Blender still depends on
it, should be dropped when we try to support multiple scene editing.
Change was planned for a while, but need this now to be able to call
update without a context pointer.
eg.
scene.objects.link()
object.constraints.new()
mesh.verts.transform(...)
mesh.faces.active
PropertyRNA stores an StructRNA pointer where these can be defined.
* The python 'math' library is now included in the py-namespace used to evaluate button expressions. So it is now possible to do 'radians(somevalue)' to get a rotation value that Blender can understand...
* Shapekey path getting function now uses the appropriate wrapper for grabbing the pointer to the ID block for the ShapeKey
* Made the Graph Editor's minimum zoom size finer...
* Mouse wheel now scrolls the list.
* Up/down key and alt mouse wheel change the active item.
* Adding/removing items from the list now automatically scrolls so the
active item is in the view.
* Shift mouse wheel changes the size of the list widget to display more
items. Lazy replacement for a proper grip.
* Shape key list now displays the influence value next to the name,
* Also fix the range of the value slider to match the defined min/max
range.
* Now the old/new names get tagged with [" "] before the search and replace operation, which should alleviate problems with searching for 'bone' and ending up with all instances of 'boney' 'boney.r' etc. also getting renamed.
* Cleaned up some compiler warnings, and removed an unused function from an earlier attempt at this work.
RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily.
The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
