UI bug: when a button has an open menu, the menu closed on any
mouse-over of other buttons in this panel. That's not too bad,
but it didn't check for whether the mouse was already inside the
menu itself (respecting safety region).
The bug showed error on zoomed in UI, using FPS presets, in case
the menu-button was drawing aligned with other buttons. A real
boundary case... :)
.blend1 etc backups.
Proves again that lazy coders only make bad code :)
Implementation note:
The filewindow now recoginizes .blend version backups as
a special type, so filtering for .blend files themselves
ignores it. However, they're recognized correctly as valid
.blend files, and draw an icon as .blend file when filtering
is off. Can become a distinct icon if we want...
older GLSL versions (< 1.3)
Thanks Matthew M:
- adding mat3 from ma4 function
- removal of transpose()
And I've hacked in myself a textureSize() replacement, the image
size gets passed on to function now.
oldbump -> original
newbump -> compatible
*new* -> default (3tap)
*new* -> best quality (5tap)
the latter two have an option to apply bumpmapping in
viewspace - much like displacement mapping
objectspace - default (scales with the object)
texturespace - much like normal mapping (scales)
were getting formed wrongly
Although the RNA paths for the custom properties could get evaluated
correctly, keyframe status highlights in buttons didn't always work
correctly, and would lead to a duplicate F-Curve for the same setting
getting created.
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
* Caching of the start and end stills were just referencing the original imbuf (which got premultiplied after the caching), so as a result most of the time the premul was applied twice.
* Now the start and end stills are stored in the cache as duplicates of the original (non modified) imbuf.
disable getattr metaclass forwarding attributes from the python class, eg:
bpy.types.Scene.foo != bpy.types.Scene.bl_rna.properties['foo']
... This was convenient but too tricky to properly maintain with attribute assignment and attributes defined within the class.
avoid doubles in dir() by converting to a set and then back to a list.
they have some rotation-affecting constraint (i.e. Track To and Copy
Rotation) targetting, transforming the objects (directly, using GKEY
-> grab) becomes unreliable.
This was caused by a typo in some code checking for some
OB_NO_CONSTRAINTS under "flag" instead of "transflag"
The console was getting flooded with output like
g
i
i
...
all as a result of what looks like a debugging print. Whoever put this
in, you can get back your debugging prints by enabling BF_GHOST_DEBUG
in your local config :)
For Constraints, there's now a working "Local" Space for Objects
without parents. This is defined as relative to the object's rotated
set of axes which results from rotation that gets set via "rotation"
transform properties.
I'm not sure whether this different behaviour between parented and
unparented objects will be too confusing (and thus require separate
settings + a round of version patching), so I'll wait until we get
proper testing from experienced riggers first.
