Thank you so much, @Sybren A. Stüvel (sybren) for fixing this crash! Does not affect 3.2.0 Beta, branch: master, commit date: 2022-05-17 19:22, hash: rB35e73aa3472a which is what I've rolled back to for now. :)

I too would really appreciated this functionality. I have a scenario where a weapon prop transforms into multiple forms, but I need to set a particular set of keys on the bones to start with (location for some bones, loc + rot + scale for others, and loc + scale for others). It would be nice to just copy the existing keyed channels from one Action and paste into a new Action and have only those keyed channels automatically created. Of course you could set loc + rot + scale keys on everything and then paste in, but it makes the Action needlessly cluttered with unused keyframe channels. To avoid this, I find myself having to re-key the same channels over and over on each Action which can be rather tedious. :-)

Just discovered this in 3.2 beta. Very bizarre behavior indeed. I thought the curves were actually broken, but it's nice to know it's just a display issue. Would be so great to have this addressed as it makes editing the curves of reversed NLA clips impossible. For now, I will have to manually mirror the keyframes in a new clip rather than using the "Reverse" option. Thanks to the devs for your continued improvement of Blender!

Just want to thank you guys again for your incredible work! I was finally working on game animation in the NLA editor today in 3.1.0 and the old auto-reset issue was driving me crazy. I switched to 3.2 beta and no more problems! Night and day! Fantastic!! :-)

Thank you so much @Howard Trickey (howardt) for that very detailed reply. I can see this issue is a lot more complicated than I had assumed, and I'm glad you were able to fix the zero-area polygons issue.

In case it may be helpful to someone else, you may want to bake your textures from duplicated objects that have the bevel modifiers removed. This way you can bake without gaps or other potential errors. Then on your original object, apply your bevel and other modifiers and assign the new textures you baked. If the extra generated UV seams fall along sharp edges (they most likely do), then there shouldn't be any additional vertex cost in a game engine, otherwise you can optionally clear those new seams. Depending on the required precision of your diffuse / roughness / normal maps, etc, you may be able to completely get away without having to stitch any of the torn UVs back together, but your mileage may vary. :-) However, if there is noticeable stretching or other artifacts in the material you will have to either stitch the UVs or re-unwrap after the Bevel Modifier has been applied and bake to this new UV map.

In addition to potentially stretching textures in undesirable ways, one of the destructive side-effects of this bug is how texture bakes will get messed up because of the triangular holes ripped in the UVs. Stitching torn vertices in the UV editor is unfortunately not very straight forward, and becomes quite tedious for many hard-surface mesh parts. I confirmed the issue existed since at least 2.79b, so it is not a regression. Strangely, it seems increasing the Bevel Modifier's "segments" to an even number like 2 or 4 prevents the issue of split UVs on the angled pieces in my test file, but then the straight pieces still get split UVs, and of course, UV seams are not preserved either (they also get split apart). Having unnecessary UV seams is not ideal for game assets, as the extra seams will increase the vertex cost, and having unnecessary geometry (from extra bevel segments) will also negatively impact performance. It appears the only way to currently mitigate these issues is to set all seams and perform all UV unwraps AFTER the modifiers have been applied. This is a destructive workflow and can also mean an enormous amount of re-unwrapping for detailed hard-surface models that have already been unwrapped.

EDIT: The following information was incorrect: "Additionally, some UV edges generated from applying the Bevel Modifier are left untouched completely and simply get stuffed under the original UV edges". It appears (at least for my test .blend file) the new algorithm in 3.2 is just splitting the bevel operation between the straight and the angled UV islands, rather than keeping the bevel on the angled island (as in 3.1). The rest of the info shared still applies, however.

Thank you so much, @Howard Trickey (howardt) for your work on this! I'm not sure if I've downloaded the correct beta build for 3.2, I have tried the latest 35e73aa3472a but it seems the issue is persisting, except it manifests in a different way than in 3.1.0. Please see attached screenshots and test .blend file. When one applies the Bevel Modifier, different results manifest in 3.1 and 3.2, but neither seems to be correct. I don't believe the bevel modifier should be splitting ANY UVs based on an algorithm, but rather keeping any new generated vertices joined and scaled out evenly from where they originated. It seems the algorithm in 3.2 is currently putting the inner vertex at the center rather than merging it with the one below it, and is separating the outer two vertices rather than merging them at the center. Additionally, some UV edges generated from applying the Bevel Modifier are left untouched completely and simply get stuffed under the original UV edges. I have noted in the final screenshot what should be happening to the vertices. If your fix has already corrected this and it has simply not been applied to the latest 3.2 beta build then I truly apologize!

This is fantastic-- thank you all so much! I am nearing the character animation phase of my project so this is perfect timing. Can't wait to try out the new patch! :-)

Woo-hoo!! I thank God for helping me fix the original poster's Cat Rig also. @fisly (fislysandi) here is what you need to do (if you get stuck, just let me know and I can provide the fixed .blend file of your cat rig:

I uploaded a sample file with super easy instructions to reproduce based on the provided .blend, which also reveals the exact rounding error I mentioned earlier:

SOLVED!! I just want to thank the Lord Jesus Christ for showing me the solution, which I will share here. Firstly, the face rig on my character had been "upgraded" to the new face rig AFTER I had already aligned the bones. When Rigify added the new glue bones, it likely produced a rounding error smaller than 3 decimal places, which caused the Tail coordinates for chin_end_glue.001 to become misaligned with the Head coordinates for "lip.B.L". Both bones showed their coordinates as:

I think I just ran into a similar "Could not match control node" error using the Human Metarig, in this case involving the "chin_end_glue.001" bone. I was able to reproduce the error on an unedited Human Metarig by moving the tail of the bone away from touching the head of "lip.B.L". However, after snapping the tail of chin_end_glue.001 to the head of "lip.B.L" the rig generated without errors. Unfortunately, this fix only worked in an unedited stock rig. I was unable to fix the error in my own edited rig despite making sure the affected bone's head and tail were perfectly aligned.

Will do; thank you, Omar, for taking the time to read the feedback. It's very appreciated. Have a great week. :-)

Thanks so much @Brad Clark (RiggingDojo) for the update! And a huge thanks to @Wayde Moss (GuiltyGhost) for this fix and @Ramil Roosileht (Limarest) for updating it for review! I still have that 12-30-2020 patch build on my system, and can't wait to see this enter Blender 3 territory. Now... if only there was a Blender build that included both this amazing D14230 NLA Editor fix and the incredible shapekey undo fixes from D14127... well that would really be a dream come true! :-)

You're welcome, @Campbell Barton (campbellbarton) ! I should be able to file a report within the next few days. Have a great week. :-)

Thank you so much @Campbell Barton (campbellbarton) for your excellent work! Looking forward to working with this final version. Have a fantastic week!

You're welcome @Campbell Barton (campbellbarton) ! Sure, I can switch further discussion over to D14127, but I didn't think non-devs were supposed to comment in there. :-)

Additional info-- I just discovered a third scenario:

Hi @Campbell Barton (campbellbarton) , firstly let me say this fantastic and does indeed solve the issue with using Undo on the Basis key!

Amazing--- downloading the Windows build now, will test immediately and update you. Many thanks, @Campbell Barton (campbellbarton) !!

This looks incredible, @Campbell Barton (campbellbarton) !!! Thank you so much! I can't wait to try this fix out once it makes its way into one of the daily builds :-)

Thanks Mysteryem. T79892 is indeed the exact bug I was referring to. Good find. Your explanation in that thread also makes sense, and I agree that either the new Basis should be forced to be relative to itself or allow the UI to display which key the Basis is relative to. This will help avoid majorly confusing scenarios. Glad the devs are already aware of this issue.

Thank you, everyone, for looking into the issue. I do save often with incremental file numbering so that can help should something go wrong. Of course, just being aware of the issue while I'm editing the Basis key is the best deterrent at accidental data loss. However, other users who encounter the issue for the first time would not be so fortunate.

@Philipp Oeser (lichtwerk) Thank you, Philipp! I am indeed surprised this bug has managed to survive untouched for 7 years, but perhaps it went overlooked because editing the Basis shapekey is thought to be taboo by some? However, it's truly a vital feature during character development to be able to freely iterate and update the Basis shapekey at will. I consider this a high-priority fix because of the potential to literally destroy hours of work (and hundreds of individual actions) with a single lethal button press. Only actions done AFTER pressing Undo will be successfully propagated. If one has unwittingly saved their .blend file, and their Undo buffer is not set large enough, their entire project may be irreversibly damaged. I trust the talented Blender devs will look into this and find a great solution...

This is an extremely severe bug, and there is no workaround whatsoever. Any application of Undo in the Basis shapekey, even just ONE press of Undo, will render ALL changes made to the Basis shapekey during that editing session UNTRANSFERABLE to existing shapekeys. I just tested several combinations of Vertex > Blend from Shape and Propagate from Shape, and there is NO combination that can transfer your changes in the Basis key correctly. Unfortunately, this bug renders Blender's shapekey system completely unusable.

@Philipp Oeser (lichtwerk) Thanks Philipp! Glad the devs are aware of this issue. I admit it's quite confusing to see inverted normals when modelling with the mirror modifier. A temporary workaround is to either turn off the "Cage" display on the modifier or enable "Face Orientation" in the Viewport Overlays so one can tell what normals are truly flipped.

In T68915#1217256, @Jeroen Bakker (jbakker) wrote:

Please don’t mention other software solutions.

Thanks @Philipp Oeser (lichtwerk) for letting us know! I thought this had to be a bug and installed the latest 2.93.2 only to find the same issue. Quite honestly, this setting should never have been buried deep in the User Preferences, as it is every bit as common as toggling "Viewport Overlays". This setting should DEFINITELY be moved back to the "View" menus of the Action Editor / Dopesheet / Graph Editor under the title "Show Group Colors", where it used to be. This is the only logical place where such an important setting that affects the "View" should reside. Thanks, and we all truly appreciate your incredible work on Blender!

In T68915#1201198, @Paul Kotelevets (1D_Inc) wrote:

hard to manage (hundreds collections with different setups, and you will never met a deadline).
Complete system design is about management design as well.

@Michele Faccoli (MicheleFaccoli) That is pretty much how Blender Internal Renderer (2.79b) used to work. It had the ability to BOTH limit light influence at the material level (by adding lights to a Light Group, then selecting that Group for your desired materials), AND limit lighting at the layer (collection) level (to only affect objects in the same collection as the light). Both ways are incredibly useful. I think adding lights to a Light Group (Collection), and having an option on objects (or materials!) to restrict lighting to that Light Group (similar to Blender Internal) would be great. However, there should also be an option when you right-click on a collection of objects to "Limit Lighting to -> (Light Group of your choice)". That way you have both per-object and per-collection light control. To avoid conflicts, any Light Group specified at the object (or material) level would override any Light Group specified at the collection level (this is also the override behavior Blender Internal used). :-)

Finally got a chance to use the new Mantaflow fluid sim and I was wondering what on earth was wrong since the cache was not updating when a change was made to the flow object (unless some random parameter was changed in the Domain object). I am using 2.92 official release. Does anyone know if this bug has been fixed in any of the experimental builds? Mantaflow has a lot of potential but previewing results in real time is extremely difficult at present. Thanks for your time!

Yes, I noticed this is unusually slow. In this video by Zach Reinhardt, the lasso trim tool appears to work quite fast compared to on my system. Same in both Blender 2.92 official and 2.93 alpha. I'm using i7-5930K 6 core @ 3.5 GHz (3.7 boost), a GTX 970 with 4 GB, and 32 GB RAM, and Zach is using a i7-7700 4 core @ 4.2 GHz , a GTX 1070 ti with 8 GB, and 64 GB RAM. However, the operation in both cases is ultra-simple: using the lasso tool to cut the default rounded cube, which has a mere 24,578 vertices. Is this operation heavily dependent on CUDA cores (1664 vs 2432), because judging by the monitors on my system, the simple operation barely touches my GPU RAM, GPU load, or system RAM? Link to Zach's video: https://youtu.be/tQfFlzHJJ88?t=289 (The same operation hangs for 7 seconds on my system). Thanks for looking into this.

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: