You're welcome, Wayde! And thanks for that explanation-- that clears things up. Glad to hear you've already made a patch for the Hold Forward inconsistency. :-) Looking forward to seeing this in the official release soon. Until then, I will 100% be using your December 30th build for any serious animation work! Have a great day!

EDIT: I can see now that the generic track settings for Extrapolation and Blending have an effect on new actions that have not yet been "pushed down" into strips. However, there does appear to be a bug here, as actions set to "Hold Forward" will incorrectly exhibit "Hold" behavior until they are pushed down into a strip. However, if the action in limbo has its Extrapolation set to "Nothing" it will behave as expected, even if not yet pushed down into a strip.

@Wayde Moss (GuiltyGhost) Apologies for the very late reply, Wayde. I finally had opportunity to test your build: 2.92.0 Alpha, branch: tmp-T82230-nla_remove_hold_reset_behavior, commit date: 2020-12-30 19:30, hash: rBdc4f3080fde5

Yes, I've just run into this issue again, where accent area lights placed along the length of a client's product are erasing the key light's shadow. Without light linking in EEVEE, one must use short custom distances on the accent lights so they cannot affect the key light's shadow. However, that is a poor workaround since it weakens the lights too much. It's extremely necessary to be able to isolate the influence of your accent lights for commercial product visualization. Thanks to the talented Blender devs for investigating a solution to this much needed feature!

Awesome; thanks Wayde! I will try to give this build a try over the next few days. Much appreciated!

Wow, that sounds fantastic, Wayde! Thank you for addressing this. Yes, I would certainly be interested in trying this feature if it has not been added to the daily builds yet.

One other significant limitation, which I assume is related, is that SSR does not work as expected when using a mix node. SSR is supported ONLY for input 1. You cannot mix between materials of varying roughness, if you try to, the screen space reflection simply fades to the world color, rather than blending in the second material's roughness. Even in the most basic setup, such as mixing between 2 Glossy shaders set to "Sharp" (where one is white and the other is green), only the shader connected to Input 1 on the Mix Node will have SSR. Even when the Mix Node is set to 1, no SSR will show for the second material, you must unplug it from the mix node for SSR to work. This means that any mixing between roughness MUST take place in a single shader. Within a single shader, SSR can display varying roughness perfectly fine, but completely breaks when used with a Mix Node. Since HDRI reflections can display varying roughness when used with a mix node, it would be great to see SSR supported in this way too. Hopefully a solution can be discovered to resolve this issue as well as provide the much-needed SSR in clearcoat reflections. Thank you!

It's unfortunate this limitation exists in Eevee, as it inhibits the creation of metallic car paint shaders. I came across this limitation today during a client's project. The only workaround is to tamper with the basecoat roughness, but then the material darkens far more than it should. SSR in clearcoat reflections is definitely a must to more accurately mimic the real-world response of these type of materials. Hopefully this feature can be implemented at some point. Thanks to all the Blender devs for their amazing work.

Just came across this myself while attempting to sculpt vehicle tire normal map details based on a manufacturer's provided texture map. Work is for a client. Texture is not shown in Dynamic Topology mode either. This seems to be a major limitation in Sculpt mode. While my simple scenario can likely still be accomplished by other means, the ability to sculpt while displaying a UV mapped texture would be a brilliant feature to have, especially when using a photo reference. Hopefully this can be added in a future release. :-)

@Juan Gea (juang3d) Thanks Juan for that info! That sounds like great additions; I will have to try those builds out. I'm sure the talented devs will find a way to implement light linking as well in time. So many great features being added to Blender these days- it's hard to keep up with them all! :-)

E-Cycles has a feature called light groups, but I think this more or less controls the ability to adjust isolated lights after a render, rather than having isolating lights affect only certain objects (which is what Blender Internal could do). However, I have not used E-Cycles before, so others would know better on this. I think the idea of light-linking received pushback from the devs initially because it was deemed a non-realistic technique and Cycles is a realistic path tracer. Nevertheless, the concept of light-linking is the only economical way I can see of providing specific accent lighting to a large quantity of isolated objects without using a massive amount of render passes. For example, for my current architectural project, I am lighting kitchen cabinet hardware independently and then rendering it in its own render pass, to avoid unwanted reflections of these lights in the cabinets themselves. This works okay for this scenario, where repetitive objects all can share the same render layer, albeit at the cost of extra render time. But if more passes were needed, the process would become very tedious very quickly.

Fantastic; looking forward to using this! Now if only I was familiar with how to build Blender from source-- but I guess I will wait for this patch to trickle into one of the daily builds. :-) Great work, Harley!

@Harley Acheson (harley) I can make a patch that restores it...

@Kasimir (Avion) There was a branch of Blender back in 2016 by Tangent Animation on Github that has this feature for Cycles. They used light linking in a production environment to light feature film shots, and indeed, it is a necessary function to add detail lighting without having those lights reflecting on unwanted surfaces. Currently, one must separate their scene into multiple render passes to achieve this which is unwieldy for many objects that require detail lighting. Unfortunately, the branch was from the 2.78 era. Really looking forward to this feature coming to Blender 2.9+ soon. Even having this feature for Eevee would be a huge plus, and would bring back that incredibly useful feature lost with Blender Internal renderer. You can vote on the feature here: https://blender.community/c/rightclickselect/5mfbbc/

@Harley Acheson (harley) I see; thank you Harley. Yes, having more options is always best; not everyone will be using my screen layout or scaling. If the compact UI doesn't work at this time, that's totally fine. I'm sure you and your team will find a fantastic solution. :-)

@Harley Acheson (harley) Thanks Harley for the explanation! For me, using scene statistics as a 3D View overlay is not an option. I tried it and personally found it too distracting since it is vertically arranged and overlaps a lot of my screen real-estate (I typically work with a UV Editor and Shader Editor window open at all times, so the 3D view is limited to a smaller center screen). Probably reverting to the 2.83.3 three-section tried-and-true layout would be best. But if possible, it would be great to also remove excess space between the tooltips, as shown in my "Compact" mockup image above, for optimum usability. Thank you so much for all your great work! You and your team are doing an incredible job with Blender 2.9.

@Germano Cavalcante (mano-wii) Thank you so much, Germano for looking into this.

I should note that the second and less important issue could very easily be remedied by first removing the wasted screen space and simply adding a pipe character "|" between each tooltip, even as you already have for divisions between scene statistics on the status bar. Please see images below to see the huge difference. As for the first and most important issue (updates appearing offscreen), this can be rectified by reverting to whatever code Blender 2.83.3 was using here, so the updates can appear front and center on the status bar where they should be. Thanks again to the devs for all your diligent work - it is greatly appreciated!

Awesome, thank you, Germano! This will make everything so much better and more intuitive now. Have a great day!

@Germano Cavalcante (mano-wii) Thank you, Germano. I think your solution would be best. When deliberately constraining to an axis while extruding vertices or edges, people already expect the current "Transformation Orientation" to be used. Likewise, when deliberately constraining to an axis while extruding a face, the current "Transformation Orientation" should also be used.

@Germano Cavalcante (mano-wii) Thank you Germano for that explanation. I can see there was a bit of inconsistent behavior even in 2.83, although under normal circumstances, I never ran into it. However, for consistency, when performing a face extrude, whether in X, Y, or Z, the behavior should default to the constrained normal Z move, but upon pressing X, Y, or Z, it should immediately switch constraint to whatever Transformation Orientation has been set in the Header (Either Global, Local, Normal, etc.). There should be NO attempting to "guess" what the most helpful orientation should be, it should fully respect whatever has been manually set in the Transformation Orientation dropdown.

Thanks so much Germano for that info. I had not seen that checkbox before, so that's very helpful. Yes, I guess I could add this in the feature requests. However, since the image gizmo does not "technically" affect the object transform values, but the end result of using it DOES affect the object's perceived transform, such contradictory behavior would normally be considered a bug to most users. However, I'm glad there is more than one workaround to disable it from getting in the way. Thanks again for your help!

I thank the Lord Jesus Christ for showing me a temporary workaround:

Thanks Richard for reopening it. I appreciate that.

Hi @Richard Antalik (ISS) the issue is still occurring. I took a screen recording of it just now: https://youtu.be/a7W8NiobWpY Short clip shows how scrubbing over an audio clip causes an image sequence on the track above to disappear in the preview window, but scrubbing over a blank area or over the image sequence itself shows the video playback correctly. Thanks for looking into this bug.

Thanks so much @Jeroen Bakker (jbakker) for triaging this. Looking forward to having this serious issue addressed! I suppose the issue was able to go over 4 years without veteran animators complaining because traditional "straight-ahead" and "pose-to-pose" animation doesn't typically stitch individual animations together, like one does in a game engine. However, with a name like "Non-linear Action Editor", being able to move clips around in a "non-linear" fashion is obviously expected, just as it is in a NLA video editor. But to this day, that is not possible without destroying the extrapolation settings in all other clips. In my opinion, the ability to re-use animation clips and stitch them together without destroying all others is as fundamentally important to workflow as traditional animation styles. At the very least, it gives game animators a means to test switching and blending between their animated actions before exporting to the game engine, and a viable way for all animators to create entirely new sequences from pre-existing work. Thanks again to the Blender dev team for investigating a way to solve this.

Just for future reference, the UV stretching issue (caused by assigning an image with a different aspect ratio than the image the unwrap occurred on) can be corrected by the Magic UV addon (included in Blender). The feature is called "Preserve UV", accessible from the "U" menu in edit mode in the 3D view (once Magic UV is enabled). Example .blend attached.

Yes, I hope this can be fixed as well. I just came across this behavior myself trying to snap a nurbs surface to other vertices. It definitely would be beneficial to have vertex snapping for nurbs surfaces for greater precision. Thanks!

@Howard Trickey (howardt) Thanks so much, Howard, for that detailed explanation and clarification! I look forward to seeing the advanced solutions you are creating.

In T71524#810103, @Stanislav Blinov (radcapricorn) wrote:

Current Booleans indeed cannot reliably work on open geometry. We would have to wait for the new Boolean implementation, which is supposedly not that long.

Thanks Philipp. Well, since the difference operation is supposed to be "subtract" (ie. cutting a hole), the 1st example which "combines" the geometry together is incorrect, while the other two examples work as expected. But as mentioned, this error only occurs when the object being acted upon has no thickness. So yes, it is definitely a strange bug and I hope the super-smart Blender devs will discover the root cause of this... :-) And wow, I didn't even know about that bug when applying rotation. That makes absolutely no sense. You'll notice that it switches to the same incorrect "combine" mode after the geometry is applied, so no doubt the two bugs are somehow related...

Adding a solidify modifier at the top of the stack and un-checking "only rim" appears to cause the boolean operation to behave as normal. This could be a temporary workaround, but reveals that the Boolean Difference operation CANNOT presently work on objects without thickness (ie. a 2D plane).

I can confirm this bug affects every version of 2.8, including the official release. I tested every build I had on hand all the way back to Blender 2.8 Hash: 388ff003e28b (v 2.80.48), and they all behave the same. The only version of Blender where this bug does not exist is 2.79.6.

In D5659#129673, @Brecht Van Lommel (brecht) wrote:

I think it's a bold decision to remove ESM and VSM. But if we think of Eevee more as a preview or final frame renderer than a game engine renderer, then it does make sense to go for more accurate results with less parameter tweaking.

Victory!!! Regarding fixing the AO flickering, I thank God for showing me two solutions:

I haven't found a workaround yet. I tried making a larger proxy object with a transparent material to sit over top of the smaller object to hopefully fix the AO flickering on thin objects. Unfortunately, it did not help at all. This issue makes EEVEE unusable for animation... I'm considering moving this project to Unreal Engine, unless someone has any ideas on how to fix this.

I see; thanks Marcin. I'm going to investigate if there's any kind of workaround for this flickering issue while we wait for a fix to be implemented.

@Clément Foucault (fclem) Clément, would adding the ability to bake the AO for static (non-animated) objects as part of the Bake Indirect Lighting feature be a possible way to solve the flickering during animation, even without needing a thickness heuristic? I reduced the AO distance much further than what it should be for my architectural fly-through animation, and the AO still flickers badly. Merci de votre aide...

Yes, I was experiencing this same issue. Thanks for posting the videos, Marcin; that clearly shows the AO pulsing I was having. I assume the only workaround at present is to reduce the AO distance?

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. :-)