Release notes look like this was fixed in Mesa 21.3.6:

Curves with a bevel_object also count as double.

In T94209#1293600, @Tom M (tlm) wrote:

I was having a very similar problem of viewport flickering in Fedora 35 in Blender 2.93, 3.0 and 3.1. The problem went away after updating Mesa on my system, which only required a 34 MB download. Thanks.

The update command was simply

sudo dnf update mesa*

In T95461#1301171, @Hans Goudey (HooglyBoogly) wrote:

I think we'll end up removing the texture socket completely when we remove the legacy nodes "before 4.0".

@Richard Antalik (ISS) Ah, um. I don't know how the account above managed to close this, but it appears it was never triaged.

I do not believe it's related to the other graphics driver issue. I'm using an unaffected version of Mesa, and haven't observed any of the other of issues from T94209.

@Marc-Andre Voyer (ispaure) The SVN files for Blender 3.1 have a patched Python 3.10 version in them, so hopefully that will bring the fix to more users.

In 2.93 at least, this still happens if the vertex group hasn't been "initialized" on the modified object by having been assigned to at some point. I will open a new issue if it still happens in 3.0.

Still in Python 3.9.6. There doesn't seem to be any backport for version numbers below 3.10.

Hm. There isn't any way to specify the popup menu size from the Python API though, AFAICT.

The current behaviour also projects even if the source vertex isn't even on the screen/view frustum, which naturally leads to some rather unpredictable behaviour.

Results from trying to nail down causes of the remaining variance in my project:

That's odd.

I submitted a fix upstream, which has now been merged:

I opened an issue upstream, for the Python standard library:

For the other users in this thread:

This may have been fixed upstream:

Ah. This seems like probably a dupe of T88986. I focused on the factory aspect in my search, so didn't catch that one until I went back to trying to find a workaround.

Do AO or shadow settings affect this?

Here's a somewhat shorter reproducer that triggers invokes the operator and triggers the crash automatically:

I kept running into another issue a while ago that was similar but with changing the Redo dialog instead, in between script updates and re-runs.

Right, sorry about that 😅.

Discussion from D11344:

Discussion from D11344:

@Philipp Oeser (lichtwerk) Aah, sorry! I had the information typed up, with screenshots, the documentation page, and even a Stackexchange link, but didn't hit "Submit".

Will this properly handle Collections instanced as Empties— Including arbitrarily deep recursive layers of subcollections and highly interdependent global-space modifiers?

I think this only affects the UI and not the underlying property, right?

What would be the application of this? Isn't the number of targets strictly determined by DriverVariable().type?

The last one also seems to have much greater weight for changes in normals across a continuous surface than for changes in depth, with sharper darkening of crevasses and brightening of ridges, and much higher contrast in general.

This is a View Transform/Color Management thing.

I know I'm just a user with an opinion.

@Falk David (filedescriptor) Anisotropic/non-uniform scale is explicitly a part of the description and reproduction steps. Applying the scale doesn't solve the problem so much as avoid it, and isn't an option for objects with shared data.

Iterating over and checking for object containment in collection object values also fails, but checking for object name string containment in collection object keys works.

I was hoping that someone would provide information which would make it easier for me to figure out reproduction steps.

Okay— Actually, "Using fallback" seems to be caused by Boolean modifier in 'FAST' mode with overlapping geometry, and the slow performance may be caused by that geometry being fairly poly-heavy and then being propagated along a series of other Boolean modifiers.

Ah, yeah. I guess there's two contradictory behaviours: Custom properties are usually item keys, but dir() seems to treat them like attributes? Which one is more correct, and does anything rely on the current behaviour of dir()?

Without knowing how exactly the stale data in question is structured, this also raises some security questions for me. Does the kept panel include its input fields? Suppose I have an add-on panel from a proprietary cloud hosting or rendering service. I've input an API key into the panel, and saved the file. I then uninstall the add-on, so I cannot see the panel and have no way of know it's still in the file. I upload a stripped-down version of the file to a website like StackExchange. Is my API key now floating around in a .blend on the open Web?

If I've understood the situation correctly, then I'd like to humbly suggest not using the simplest option. As a user, I don't really like the the idea of stale UI cruft being left in the file.

In T85223#1104086, @Sven Stein (HADESBLACK) wrote:

Okay, I just tried appending my models into a new blend file and it works. All my objects got imported correctly and the problem with the modifiers is now gone. God bless the "Append" function!

This happened again for me, in the same project:

@Abnilson Rafael (UltraBurstXD) I'd like to add that you shouldn't have to let weak hardware discourage you from CGI if it's something you're interested in or enjoy. I used to use a single-threaded Athlon64 with a similarly ancient and weak nForce 630 back in the Blender 2.5 days, I've heard of people who used original (1990s era) Pentiums around the same time and made amazing art, and I still rely on an Intel IGPU most of the time.

Again, "normal", "good", and "bad" are all subjective— They're not software bugs, they're opinions and judgements. And from the hardware you've listed and the scene settings you've described, the behaviour you've described sounds entirely "normal" to me, or at least plausible.

What is the specific problem, and expected behaviour? "Slow" on its own is vague, subjective, and a product of many factors, including hardware. Is it, E.G., 50% slower than it was in the last version? Or is it just "slow"? "Remarkable quality" isn't really related to speed. "Incorrectly" is also vague, unless you specify in what actual way it's incorrect.