I encountered this issue with my own Blender key config. In fact, both of the Shift-Left Mouse commands for view3d.manipulator were somehow missing, although I don't recall deleting them. I added them both of them back in manually to my key config, exactly as in Blender's default config, but they still don't work. They only work in Blender default. I'd really like to be able to use this feature with my custom config as I have some very handy shortcuts I use frequently, namely:

I thank God for a much simpler solution to this issue. Posted answer on StackExchange here.

For anyone who has come across this issue in 2018:

Whew... I was finally able to wake it up in the most bizarre way! If the driver is in this frozen state, you MUST add a variable that references an OBJECT ID Block and add some animation to the object, then set the driver variable type to "Transform Channel". Trying to use an animated single property (such as evaluation time on a Path) will NOT work. Of course, this placeholder variable does not need to be used in your scripted expression, it simply sits there to prevent the driver's door from locking! :-)

Wow... this is insane. Even though I was able to successfully wake up the driver by adding a variable in a new project, in the original project that glitched, it has remained frozen. Still investigating why this bug is occurring. I tried the f76d49e latest build along with the 8928d9270f official 2.79a build and neither can wake up the drivers! The glitch had occurred in the earlier d640ce4 build.

I couldn't figure out why Blender drivers suddenly stopped working without explanation even with Auto Run Python Scripts checked. But I thank God for showing me it was because a no-longer-needed variable had been deleted. Well, now I know that Blender requires at least one variable to be present even if not being referenced for drivers to execute. :-) There definitely should be a default warning of "Must set at least 1 variable for driver to execute" when adding a scripted expression and no variable has been set.

Praise God for showing me the solution! In the outliner, type "Animation", then right click on the object's animation data you want to remove and click "Clear Animation Data"; or just hit Spacebar and type "Clear Animation". It's too bad there's no interactive context for clearing this as we have with Actions, however, it's great that a simple solution is available. :-)

Ugh... the same thing is true for Curve path animation data (evaluation time). Duplicating a portion of a curve that has an animated eval time so you can modify the trajectory at a specific point without affecting the original path is currently impossible due to both paths incorrectly sharing the same data block. Does anyone know of a workaround for either issue? Surely materials and curves cannot always be animated as a final step after all duplication is done, otherwise that would hinder the creative workflow tremendously.

Ah, I see... thanks for clarifying that guys. I feel extremely privileged then! :-)

Hey Brecht, this is a phenomenal feature that has shaved off over a minute-and-a-half per frame of render time using the d640ce4 build. Are we able to get this feature in 2.79a? It's not present in the current release candidate, but this is such an incredibly useful feature for animations, saving literally hours of render time.

Wow, wow, wow!!! I cannot thank you guys enough! I just tried the new Blender 2.79 d640ce4 build, and it is FLAWLESS. All 68 material previews load nearly instantly... it's as if I'm running a new super computer! Not only that, but the small previews now accurately reflect the larger previews without sacrificing anything. It's incredible!

Sounds good; I didn't even realize the icons were using the world texture, but I just checked and sure enough, the icons for the chrome-like materials don't even represent their larger material previews at all (since my scene texture is tinted). So basically, either the solid color method or, if possible, just use the same preview image as in the larger material preview (with the gray checkered background for reflections). This would also help with visual consistency.

EDIT: I think the fixed background color is a great idea. This would only affect the small material icons and not the actual material preview window, correct?

Thanks Damien for helping out with testing this situation. I have one 5000 x 2500 .jpg image and one 5000 x 2500 .hdr image in the scene. These 2 textures represent only 2 of the 68 materials. A portion of the other materials use multiple 2K textures. So it would seem then, that even 2K textures cause Blender to slow to a crawl, as it is calculating the tiny previews at full resolution. If there was a way to calculate at lower resolution (as Damien mentioned) or to somehow locally save the tiny preview after it's calculated once so it will not constantly go offline would be great.

Sorry I haven't been able to test with factory settings at present, as I'm in the middle of working on a project; however, here is the system info file. I have about 68 materials in this project, and I add a new cube, click the "Browse Material" button to select a material I already have, and Blender will choke to a crawl for about 2 minutes as the 68 previews build.

Thanks Ronan for the info and the link about curves.

Thanks Ronan;

Thanks Philipp for the information and the tip about baking the action first. Also thanks lower case for the python code info... I will have to try that.

Here are my settings:

I can confirm this is still happening. Blender freezes when the material dropdown is opened, and the memory usage continues to climb long after the drop down is closed. Very unusual behavior. Triple buffer does nothing to remedy it.

You're welcome! Glad you got it working. :-)

Hi Juan, you might be encountering this issue? If so, I posted a workaround; and there is also a solution inside UE4 if you are using that game engine. I hope this helps!

Thanks Philipp. Is there any chance this bug could be fixed by one of the devs within the next few days? It is really slowing down the animation of a project which I need to submit by the 11th. It basically doesn't allow the Non-Linear Action editor to be used in a Non-Linear manner, as any update to the strips will destroy the settings in all the other ones. This forces you to have all strips start at frame 1, even if the action doesn't occur until frame 100 (essentially a Linear editing workflow).

This bug would explain why I would sometimes experience weird glitchy behavior in an animation project back in 2015. Now that I have discovered it was all due to the NLA strips switching to "Hold Forward", I will have to be extremely cautious every time a change is made in this new project, unless someone has found a workaround.

It appears this has also been reported here.

No problem, thank you Brent and Sergey for your clarification. I ran into this issue initially creating large environment assets for use in UE4. The scene unit scale has to be set to 0.01 to convert to centimeters in UE4 (at least it used to, not sure if it's still required). I had my clipping distance set to 1 KM to accommodate a very large mesh, so I initially couldn't figure out why the sculpt tool wasn't working. :-) Thanks for the helpful troubleshooting link. Have a great day, guys.

Thanks so much, Brecht, for the update! That's great to hear the smear tool has been fixed. As far as the F key is concerned, I have created 2 different keymaps and switch between them depending on whether painting or animating (this is a pretty handy work-around for the present).

Thanks Joshua and Brendon for your input. I did notice that manually setting visual LocRotScale keyframes and then hitting Bake Action produced much more accurate (but not perfect) results than just hitting Ctrl Alt C to clear the contraints. Maybe because the visual keying gets applied twice?

I can confirm there is still a very slight discrepancy (basically negligible) at times even when manually setting visual LocRotScale keyframes and then clearing all constraints manually using Ctrl Alt C. This is likely the nature of Blender not being able to truly pinpoint the position of bones affected by the Spline IK constraint after visually keying. However, there is no doubt something wrong with the way Bake Action does the visual keying on Spline IK affected bones, as 9/10 times there is a fairly large discrepancy.

Thanks, Bastien, for letting me know. I guess that would make this a feature request, then. :-) It would be great if the outliner could replicate the behavior of renaming vertex groups, except with bones. There's lots of sort options available there: you can automatically re-order alphabetically if you have "sort items by their name" checked, or, if unchecked, you can click "Sort by Name" in the vertex group specials as a 2nd step and it will update. I could see this being an extremely useful feature, as some custom-non-character rigs require many numbered bones, and in my case, the bone numbering needed to be swapped, which completely messed up the outliner. For this particular rig, I relied heavily on the outliner for bone selection and once I fixed the ordering problem, it made it a lot easier.

I had to trick it by separating all the bones into their own individual armatures then re-combining them one by one back into the original armature. This worked good since I had only 6 bones affected, however, it would be quite tedious if a large number of bones had to be renamed.

I thank God for showing me the solution! All you have to do is add a "false foot" bone that is NOT a deform bone to each leg. I named this bone FootParent.

After further investigation, I believe my issue is directly related to this issue. Apparently, when exporting to FBX, you cannot both scale and rotate the parent bone, even if the child has Inherit Scale and Inherit Rotation turned off. It would be great to see a fix for this present limitation somehow.

You're welcome. Thanks for looking into this. I'll remember to break issues up next time.

Thanks guys! Don't forget to check the link to the video example. It shows pretty clearly how the different bugs react. My apologies for becoming braindead momentarily in the video when switching between bug subjects, LOL, that was my first-ever screen recording.

Hi Aaron,

On another note, I added Blender.exe as a specified program in the "Program Settings" tab to use maximum performance, rather than leaving it as a Global setting.

Yep, that's what it was: "Prefer Maximum Performance"! That was the only setting I changed just now, and sure enough, no more stuttering. So I guess the new "power saving" modes must have been added in the newer drivers and that's what broke it. Basically then, when I enabled the screen capture settings in my previous workaround, the GPU must have kicked into the "Prefer Maximum Performance" mode, which "indirectly" solved the stuttering.

Thanks so much, Daniel! Yes, that does work, however, I noticed the settings only take effect once Blender is closed and re-opened (I tried changing the settings one at a time with Blender open to no effect). And resetting NVIDIA control panel back to default does cause Blender to re-exhibit the issue (when closed and re-opened). I'd have to try those 5 different settings individually while opening and closing Blender each time to know which of those settings are directly affecting the issue.

In T49758#403740, @Bastien Montagne (mont29) wrote:

This is definitively an NVidia dirver bug, if with one version of driver everything is OK and the next it’s not… that’s called regression. We cannot fix their drivers for them.

It's very strange how enabling Sharing, Instant Replay, and Desktop Capture in NVIDIA GeForce Experience allows me to run Multisample x16 inside Blender without any glitching at 1440p... I just tested again to be sure. However, even if the original issue can't be fixed, this workaround does "solve" the problem. Thanks :-)

Just found the solution: The UV islands just needed more padding around them. Even though they looked clear, this mip map error would show up from a distance. :-)

My bad... just checked 2.77a and it has the same UV seams issue. Apparently someone had the same issue as me back in 2007, so I guess this problem's been around for awhile. Wonder if anyone found a workaround for something with an all white texture and a distant camera? Anyway, feel free to set the original report to solved, if you wish. The NVIDIA GeForce Experience workaround seems to be an adequate solution. No idea why things had changed though on the newer drivers... except maybe when they recently overhauled GeForce Experience they broke something.

Thanks Sergey! I tested it out in Blender 2.78 with all the NVIDIA settings off and at first the issue appeared to be fixed, but when I launched a project from hard drive directly, sure enough, the lag was still there.

I am setting this back to open, as NVIDIA claims this is a Blender-specific issue. The previous info I added about enabling Desktop Capture in GeForce Experience privacy control to "solve" the issue, and disabling live replay to make the issue even worse still applies. Obviously, something major changed between the way Blender responds to 359.00 and 373.06.

This appears to be an NVIDIA issue, as the problem goes away when: