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, both "Using fallback" seems to be caused by Boolean modifier in 'FAST' mode with overlapping geometry, and the slow performance seems to 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.

In T86170#1122225, @Demeter Dzadik (Mets) wrote:

From the PyAPI:
id_data: The bpy.types.ID object this datablock is from or None, (not available for all data types)

So, on a driver placed on a Constraint property, where self refers to the constraint, self.id_data will refer to the bpy.types.Object that holds the constraint. self != self.id_data.
On a driver placed on an Object property, where self refers to the object, self==self.id_data.

This limit appears to still be in place. Is it necessary to keep it around, or would it be harmless to increase it?

@Richard Antalik (ISS) When dealing with output from generative modifiers or meshes linked from library .blend files, it's useful for me to be able to non-destructively assign a default vertex weight of 0.0 to all vertices so I can then use VertexWeightMix modifiers to add textures to the weights, combine multiple vertex groups, etc.

This happens for me too using the Iris driver with Intel UHD620 graphics.

Also, IMHO, whether or not modifiers actually use vertex group membership is just an example, and not the main point of the issue. The behaviour of subdivision interpolating vertex weights for every value except 0.0 is itself inconsistent, and could thus also lead to other issues elsewhere.

@Germano Cavalcante (mano-wii) Hey, sorry for being unclear.

I just realized my screenshots don't actually prove anything, as zero weights would be rendered black anyway. But the behaviour I described does occur AFAICT, and the test I did produces the same result with non-zero thresholds and default weights.

@Campbell Barton (campbellbarton) I don't know if there are any modifiers that *explicitly* use vertex group membership, but the VertexWeightMix modifier definitely seems to implicitly use it in the sense that it will not assign new memberships to vertices that aren't already in a target/output group. As a result, being zero-weighted has a completely different effect compared to not being in a group, which in turn can affect any other modifiers that use its output weights further down the stack.