- User Since
- Oct 12 2018, 6:30 AM (133 w, 6 d)
Fri, Apr 30
Tue, Apr 27
Sun, Apr 25
Sat, Apr 24
Thu, Apr 22
I know I'm just a user with an opinion.
Tue, Apr 20
@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.
Mon, Apr 19
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.
Sun, Apr 18
Sat, Apr 17
Fri, Apr 16
I was hoping that someone would provide information which would make it easier for me to figure out reproduction steps.
Tue, Apr 13
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.
Mar 27 2021
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()?
Mar 20 2021
Mar 19 2021
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?
Mar 17 2021
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.
Mar 13 2021
Mar 5 2021
This happened again for me, in the same project:
Mar 4 2021
Mar 3 2021
@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.
Mar 2 2021
Mar 1 2021
Feb 28 2021
Feb 24 2021
This limit appears to still be in place. Is it necessary to keep it around, or would it be harmless to increase it?
Dec 15 2020
@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.
Nov 22 2020
This happens for me too using the Iris driver with Intel UHD620 graphics.
Nov 21 2020
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.
Nov 19 2020
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.