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: