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.
