Right-Click Select This is a read-only archive
← All ideas
  • Published 5 Mar 2025

high performance impact warning

options that have a high impact on performance, like the subdivision count on the modifier, or the particle child count, or any other things that can lead to freezes or crashes

too many times ive set some value to 100 and instantly crashed blender because i wasnt sure what the value does image_2025-03-05_202233916.png

100%

Development Status: Open

Upvote 3 Downvote 0
dex_flex
5 Mar 2025

7 Comments

Lauloque

While the idea sounds reasonable on the surface, in practice, it's not as simple as it seems. There are two main issues with trying to warn users about "high-impact" settings:

  1. Adding the warnings to the settings
    Someone would have to manually go through every property in Blender, determine whether it could cause performance problems, and then add warnings accordingly.

  2. Performance impact is highly situational
    What causes a slowdown, freeze, or crash depends on many factors: your hardware, your scene setup, and even which features you have enabled. A setting that runs fine in one context might be disastrous in another. For example:

    • Setting 2000 particle children on a default system? Most users wouldn’t have an issue.
    • But if those particles instance a seemingly inoffensive mesh like a default cube, performance tanks for most people.
    • Remove a zero from the emission number, and suddenly things run fine again.
    • Disable overlays and high-end viewport effects, and even the 1000 cubes X 2000 children setup might work smoothly for some people.
    • Switch to hair particles instead, and suddenly it’s smooth again for most people.
    • Now, go back to the 100 cubes X 2000 children setup that is fine for most people, but add fancy shaders like volumetrics and diffraction glass, and rendering becomes a nightmare even on high-end GPUs.
    • For all the scenarios you can think of where it can run fine for most people, there will always be people for which it will not work.

    So where do we draw the line? Anything could be a problem under the right (or wrong) conditions.
    We definitely can't add warnings everywhere without cluttering the GUI.

In the end, experience and learning to adjust settings in moderation is the best approach. Blender already provides reasonable defaults, and users can always experiment carefully before cranking values up too high.

4
ketsebaot

for the problem that someone has to go through the properties and check if they will crash or not, this can be implemented first for the common properties. there aren't a lot of properties that make blender crash by the way .

Lauloque

My first point would be false if the second point was also false. Unfortunately, they are both true.

thorn

User has a single cube, and uses 7 levels of subdivision: no problem.

User has object with 3 million triangles, adds 7 levels: now a problem.

The problem isn't simply using 7 as the value.

But how do you want blender to calculate - without actually doing the math, which slows it down - that there will be a problem? And based on what - cpu power? Total system RAM? Total current face count in the scene? Etc.

As mentioned, this is something that the user needs to assist the software with. IE, experience and knowing the tools.

3
Lauloque

Also simple cautions. If you don't know what a property does:

  • Read its name, and its GUI context. A "display amount" in a "children" panel of a particles system, i think lots of people can guess what it might be ;
  • Hover it and press F1 to get its manual page ;
  • If you want to try changing the value to see what it does, go slow. Don't go straight away to multiplying it by 200.
1
ketsebaot

you may not know weather a 7 sub level is high enough to crash but you know a 2000 is so instead of checking weather that sub level will crash the users system , there could be a limit of where higher than that blender would show you a prompt weather that change was intentional , because this will annoy some people it may be complemented with a checkbox saying don't show again, but for sub level thats like 5000 or something giving them a chance to verify there change is a good idea i don't see a problem for it

Lauloque

you may not know weather a 7 sub level is high enough to crash but you know a 2000 is

You seem to confuse particles children and subdivision levels? The latter is hard locked at 11, so you can't even get that high unless you add multiple subdivision modifiers. For the former, see the second point in my first comment .