Linux Ranting - MMB Paste - Can it be disabled?

Recently I've been busy working on things (i.e. coding) from the Linux workstations at Uni.

During this time, I've also run into an annoying "feature" which has been causing me endless grief: MMB paste. I'd first encountered it about 3 years ago, but at the time blamed a particularly crappy little IDE for being that cause of that with some potentially weird keymappings. However, in recent times, this has started becoming a significant productivity killer, having struck on average 1-2 times a session over several days.

Here's why...

GSoC11 - Exploring and Improving Auto Clamped Handles

One of the long standing quirks of Blender's animation system for animators both new and old has been the handle types. In particular, "auto-clamped" handles...

Auto-clamped handles in action

Note how as the handles of the selected keyframe approach gradually taper off as they approach the neighbouring keyframe instead of "overshooting" (i.e. pushing the curve past the neighbouring extremes).

GSoC11 - Animation Channel Renaming

It's taken a while (including being distracted with other work for a few days), but finally it is now possible to rename animation channels by Ctrl-LMB clicking on their names in the Animation Editors (just like in the Outliner).

For instance, it's possible to rename Objects...

Actions...

Action Groups...

and more!

GSoC11 - startup.blend tweaks

I've just gone ahead and made those startup.blend ("defaults") changes for the Graph Editor, which I've been putting off for a while, namely:
1) Larger handle circle sizes
2) 'Only Selected' DopeSheet filter enabled by default (for Graph Editor) - useful when trying to just tweak animation of selected bones, though may be a bit of a pain when using the Drivers mode (?)
3) 'Only Selected Keyframe Handles' enabled by default - hides the handles of non-selected keyframes to reduce clutter

The main reason I've postponed these is because they introduce hard-to-merge stuff, though I think we should be fine now to do this.

GSoC11 - Experimental curve drawing tweak

I've just committed a small tweak which makes the active F-Curve draw thicker than non-active ones in the Graph Editor.

Pros: 
- It's easier to see which one is active (i.e. the one you're editing), especially with the handle options that most people use.
- Thickness + opacity combined are much stronger than just opacity alone

Cons:
- Perhaps it's less visually accurate - harder to tell exactly where value lies with regard to the curve line. This is a major reason I've avoided doing this before, though I suspect that it's not likely to be that much of an issue in practice (i.e. people will zoom in several times before they need more precision)

Thoughts?

The great thaw

As is customary in these parts, snow falls only last a day...

Waking up in winter wonderland...

It's been snowing all night and right through the morning, with a reported 10cm of snow on the ground. Yay!

Snow!

It's been a long time coming (3 years) since our last snowfall, but tonight, it had finally arrived!

GSoC11 - RNA Property Updates working for AnimSys

So, on a cold winter's afternoon while waiting for the first snowfall in 3 years to come (it started falling by the time I finished, but more on that in another post :D) I set to work on a problem which people have been running into for a while: RNA property updates weren't getting run by the animation system.

This hopefully shall be a useful reference for either myself or anyone who may need to modify this system due to changes later.

EDIT: the obligatory demo video...

RNA Updates demo video from Joshua Leung on Vimeo.

GSoC11 - Animator Poll #4 - Theme Colours

It's time for another poll. While I'm still working through the results from previous polls, here are some more things I'd like some feedback on, which will (depending on the result) be included on my todo-list of stuff to bunch together for a single defaults-file update.

1) Colour of Current Frame Indicator
As from the screenshots you're probably seen in previous posts of my blog, I've been trialling using a red time indicator (the traditional Blender one is green). After a while, I have to admit that it kind of grows on you. So, should we keep the old green colour, or move towards the red that I've been using?

2) Handle Colours
At the end of the day, this probably won't change to keep consistency with the 3d view, but the colours of the lines for the keyframe handles are perhaps not that clear. Thoughts on whether a new set of colours is needed here, and/or what they might be?

3) Active/Selected F-Curve in Graph Editor - do we need to highlight this better, perhaps using a white glow behind it, or go the Maya route and just highlight it in white?

More Sintel Posing Fun

Experimenting with camera angles and backgrounds...

GSoC11 - Depsgraph Hacking - Driver Updates

This week I'd set aside some time to get through some of the bug reports on the tracker. And it happens that there are some related to the depsgraph and drivers, so I thought I'd go in and give this stuff another crack to try and push the frontiers of our current depsgraph's limitations before the inevitable big recode project ;)

So the problem I set out to investigate was whether it would still be possible in the current architecture to hack the depsgraph to at least tag + flush updates for object data id-blocks (e.g. lamp data in this particular case). In particular, trying to drive the location of a cube using the distance setting of a lamp.