Here is an unexpected workaround for certain limited uses: https://blender.stackexchange.com/a/148702/39431

@Fabio Garofalo (FabioGarofalo) , that bypass unfortunately doesn't work for lights only objects, although it would certainly be ideal. According to Clément, such a feature would require "light linking", and I suppose that will enable per-object bypassing. But what I'm suggesting here is a temporary fix that ONLY applies to reflection planes, since light-linking is not here yet.

Hi again, Clément, so if specular light is evaluated separately from the reflection plane, just continue to skip evaluation for any areas covered by reflection planes during render. Just to reiterate what I and Christian Hubert are asking, is there a way to KEEP "show preview plane" ENABLED during render? Because if there is, it will make a lot of artists extremely grateful.

Thanks Clément. So could you not enable this as an option ONLY for reflection planes? For typical usage scenarios inside archviz where you have a reflective mirror or window (both of which are planar surfaces, where reflection planes are always used) enabling this at rendertime would be ideal. It's seems a shame to have a solution built-in for debugging purposes but being unable to use that tech in a practical real-world scenario. Simply turning spec to zero is too destructive and can't be deemed a workaround, unless all the other surfaces in the scene have a high roughness value.

Thank you Clément. But as previously mentioned, until a more complete solution can be found, the tech contained within "show preview plane" is indeed a solution (at least for reflection planes).

You are welcome, Fabio. Thank you for your support on the issue. I trust the talented devs will find a excellent solution for this.

This severe issue should absolutely not be closed, since a "partial solution" already exists, but needs a way to be implemented during render. The "show preview plane" option for debugging a reflection plane removes the reflections of lamps from the scene. This basic functionality is absolutely essential to produce any kind of realism, especially for objects with a mirror surface (or anything with roughness less than 0.2). Using the same tech that makes "show preview plane" work correctly, there needs to be a way to bypass those horrible reflections permanently during render. NOTE: People can always add in emissive mesh objects if a reflection of a lamp's shape is really needed.

So I tested the folder swap in RC2... you only get access to the film looks, but you do NOT get access to the "Very Low Contrast" to "Very High Contrast" settings, which is what I need if I'm using the Film preset. So I will just stick with Filmic until this is changed back. If I do need to render Film, I'd have to use an EXR and then open it in an older version of 2.8 in the compositor to apply the Film preset.

Great; thank you, James! I will have to give this a try... :-)

Nice find, James! So you just swapped one folder with another? Would you mind sharing what these two folders were named? Thanks (Now we're a bit like the MagicLantern team bringing advanced functionality to their Canon DSLRs that Canon omitted...) Hey I'm not against the Blender devs making changes, (they've made some pretty incredible ones which is hugely appreciated by me!) but as the old adage goes... if something's not broken, don't fix it... :-)

That is true, Robert, but trying to manually match the gamma response of certain presets is not something artists should have to do when we had something that worked perfectly fine. Again I say the presets should be retained until they can be replaced with HDR capable ones (although HDR is not something that is important to me).

Yes, it's very unfortunate these presets were removed. I'm still using 2.80 (sub 69), branch: blender2.7, commit date: 2019-05-17 23:36, hash: rB03672e77836d which includes a few bugs that were fixed in later versions, but at least this earlier build allows the artist full creative freedom. Hopefully we will see the decision to remove the presets reversed soon. It certainly would be greatly appreciated by many in the Blender community and aid in backwards compatibility with older Blender training out there.

Yes, it would be nice to have this fixed in 2.8 for sure. :-)

Well I'm going to chime in once more on this, Brecht, having worked with the two competing view transforms this past week. My client actually preferred the look of the Film preset (over Filmic), so that has me staying with a older 2.8 build for now. I really think the legacy presets should stay in right until the day that they can be replaced with updated versions that work with HDR. After all, why should HDR be a factor in taking away an artist's creativity? There is tons of content being made that has nothing to do with HDR. The more LUTs and grading options we have, the better. Let the artist decide if the presets will work for them or not. Otherwise, we're forced to use a stripped down version and try to recreate those classic legacy looks using color curves, exposure and gamma settings, and extra post processing when we shouldn't have to. The presets just worked before. Unless they explicitly break some new feature of Blender, I say let them remain. :-)

Oh okay, thanks, Brecht, for letting me know. I'm able to match Filmic to the old Film preset using 1.2 exposure and 0.5 gamma, but of course it misses that extra warmth the Film preset had. On the plus side, Filmic has more accurate color than Film did. I guess if leaving legacy transforms in would break something, then I'll just need to move forward without them. Thanks.

Thanks so much for letting me know, Jacques! I just downloaded the latest build (2019-06-05 13:55, hash: rB806d4fbc5e40) and it works perfectly... no more keyframe issues. :-) You all are doing an incredible job!

Thanks William. Yes, you're right, it does appear with Alt-M, but only when I switched back to the default Blender Keymap (all my custom shortcuts remained the same, since they were previously saved, but access is regained to the "Select With" and "Spacebar Action" preferences menu (which disappears under custom saves) and apparently this Merge By Distance command as well).

Yes, I've added it to quick favorites, which helps. Though it would be nice to at least have it appear when one hits Alt-M. Currently it does not, which is probably not ideal since it now resides in that menu.

It looks like this option has now become Merge Vertices > By Distance. This is such a common operation though, I'm not sure if it should be hidden in a sub menu. It's also not part of the Alt-M menu, despite being grouped with those operations.

In T64589#678453, @Brecht Van Lommel (brecht) wrote:

This is not a bug. The gizmos from the gizmo menu are shown, unless you have a tool that overrides them. In your case you have the Move tool selected, which overrides the gizmos. If you use the Box Select (or Annotate) tool it will show the combined gizmos.

Changing the icon to a new menu called "Blender" was a stroke of genius. This is no longer a problem now... thanks for your continued innovation!!

I confirm this is fixed in 2.80.69 and is working great. Thank you!! :-)

Just had to show my appreciation... version: 2.80 (sub 69), branch: blender2.7, commit date: 2019-05-17 23:36, hash: rB03672e77836d is a marvelous build... not only are there so many good bug fixes, but you guys did an even BETTER implementation of changing lamp power than what I had suggested. It now appears to be a variable driven by mouse speed rather than being a fixed rate of change which is absolutely perfect! Great job!!

Wow... thank you, Brecht! You guys are amazing... :-)

Thank you, George! Whoa... I agree with Simon, no one would think to click there. That's just a standard app icon to most people, and I would never have guessed it was even clickable... those options definitely should move back to their original menu locations. Thanks for all your hard work!

Thanks Brecht, I see you guys are already aware of the issue. :-) It affects today's build running on Windows 8.1, I cannot confirm if it affects Windows 10.

Just noticed this applies to ALL lamp settings in Cycles (power, size, strength, color, etc). Nothing updates in real time when in rendered preview mode.

Thanks Christopher. Yes, being able to enable/disable the video preview on audio scrubbing would be extremely helpful (or a switch to toggle "full comp" vs "selected track" video preview while scrubbing). :-)

I should mention drawing an object on that "correction layer" and applying an "invisible" material, with the alpha set to zero and setting the blend mode of the layer to a mode other than "regular" also is a workaround. It's just strange it happens in the first place.

Ah, I see. That's unfortunate... but thanks so much for letting me know about that... I discovered a workaround that gives me the best of both worlds. :-) Switch back to the Blender default config, activate your settings from that menu, then save a custom preset. If you need to make any changes (such as turning on extra shading options in the pie menu), switch back to the Blender default config, change the settings, then save a new (or overwrite) a custom preset. Works perfectly... thanks so much William!!!! This really made my day. :-)

In T52063#544179, @Alexander Gavrilov (angavrilov) wrote:

Do you know how game engines deal with the non-uniform scaling problem? Or is non-uniform scaling simply not used in game animation due to this, thus making any rigs using Stretch To or other similar mechanisms in effect not suitable for games? The shear problem is a fundamental aspect of any system that uses matrix multiplication based parenting.

Thanks Andy for sharing that tip! :)

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: