You are most likely out of memory, a condition for which blender is not designed to recover from in many situations. A level 9 subdivided suzanne is 128million faces and requires just over 32gb of memory here. The UI already attempts to stop you from going so high by forcing you to type numbers larger than 6 into the property. The old 2.7 series of versions has the same issue and partial mitigation.

Your second picture above shows that you are in the Shader Editor, not the Compositor. The nodes are different between them.

You did not list your driver version. For 3.0 the driver version should be at least 470 or greater. Can you double-check that?

This is an exact duplicate of T89185

In T89052#1177169, @Paul Kotelevets (1D_Inc) wrote:

How about proper default values? Something like 0.5

The name of the node will match the operation in the dropdown. If you change the operation to Lighten, for example, the node will be called Lighten. This is currently by design.

Really? A 1 gb file?

Will there be any provisions for guarding against very low voxel sizes or high octree depths? Since these are node inputs that may flow in from other parts of the graph, I can imagine it being very easy for "bad" values to end up as input either accidentally or otherwise. Connecting any input to that socket is pretty dangerous unless you're absolutely sure the value that's going to be used first.

Is there text in the upper left hand corner of the viewport that says "Loading render kernels (may take a few minutes the first time)" ? If so, if you let blender finish that task, do things work correctly?

The Automatic setting is most likely defaulting to Optix denoising which is why you see the kernels compiling. If you let the compilation process complete (many minutes), do you see the long compilation step again after?

Are you attempting to use Optix? If so that will do a quite lengthy compile, but just once for each new version of blender. After compilation happens you should not see this on later launches. Can you confirm or deny that behavior and usage of Optix (or the Optix denoiser)?

@Lukas Stockner (lukasstockner97) I think you'll have to make the call now, and various times in the future when the broader libs are updated, about which library version you want. Like for now, do you want the 1.4.x version or the newer 1.5.x version that was just released?

Blender has not made any updates to 2.92 since it was first released. You will need to contact your distribution directly to see what/why things have changed. You can also try using the builds directly available from blender.org. They should be runnable nearly everywhere.

There's 2 other active reports for something similar: T86053 (from the comments, seems that not using blosc compression works around it) and T88120 which hasn't had user input in a while.

There was a problem with builds recently that should now be fixed. Please try the very latest set of downloads from https://builder.blender.org/download/daily/

I'm able to open it here using quite an ancient setup:
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: Quadro 600/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 369.09
PC has 16gb of memory

Hopefully not forgotten?

Duplicate of T86331

That build, from the asset-browser-branch, is no longer supported. Please use a recent 2.93 alpha build going forward and enable the Asset Browser in the Experimental user preferences. I can not reproduce your issue in any recent build.

A fix for this is in the works: https://developer.blender.org/D10535 (and is a duplicate of T85985)

Most likely a duplicate of T85609 which also mentions the DOF commit.

Which exact website? If it is not from the blender.org domain then it's not an official build and the problem should be reported to whoever built blender incorrectly since we cannot help here.

This is a duplicate of T84717 and it should have been fixed today. Can you try the very latest 2.92 or 2.93 build?

This should have been fixed with last week's 2.91.2 release.

There was clear feedback/preference for 3.8 in 2021 already but the continued lag relating to updating from 2.7 complicated it. 3.9 was even mentioned as a potential target for 2022.

In T85010#1099667, @Constantine Vojik (costavojik) wrote:

With my experience this bug exists not only on rendering but also viewport shading. If I switch or add a matcap, ambient occlusion or whatever I won't see a change until I cycle through shadings.

The viewport issue is noted here T84717 and has already been root caused to another checkin. It's a different issue.

Assuming the "lock" concept is eventually accepted by the team, the multi-res modifier's levels/render_levels/sculpt_levels fields and the screw modifier's steps/render_steps fields are also candidates for locking. It would be good to at least think about applying to those as well for consistency, or having a good reason not to. I'd hate to see that one RCS closed but then 1 or 2 more pop up asking for those other modifiers etc.

The mfehidk.sys driver mentioned on the blue screen belongs to the McAfee antivirus product. If that's listed each time you get a blue screen then the problem most likely is due to that set of software.

Probably a duplicate of T84717

Cool. I'm no longer seeing any obvious bad behavior. Though I'm not seeing any obvious perf changes either, good or bad, maybe it's just slightly faster. I've mostly been trying out viewport interactive performance using the 2.81 splash screen and moving objects - slightly - in the scene.

It's also not clear to me what's really expected here. The xxx Object has 2 UDIM tiles assigned to it. Blender will open and copy around those 2 UDIM tiles as necessary. There's no attempt to guess that the user only wants a subset of them just because the object UVs are only contained inside a subset of those tiles.

It's probably the limitation listed here: https://docs.blender.org/manual/en/latest/render/eevee/limitations.html#subsurface-scattering

This is a documented limitation currently: https://docs.blender.org/manual/en/dev/render/eevee/limitations.html#subsurface-scattering

Indeed this is straight CPU so Embree. I don't have access to a GPU capable device right this moment to try another configuration.

I'm no longer getting crashes on my side but I do observe that things are not updating correctly.

Related to T83896

I'm getting a crash when trying to render the 2.81 splashscreen. Happens for both the viewport and final render. Looks like ccl::PackedBVH::prim_tri_verts is uninitialized. This also occurs when using -t 1 on command line.

This issue is most likely a duplicate of T83300 which is now fixed in newer daily builds. No word on if it will make it back to the 2.91 series yet.

Duplicate of T83347

This issue is most likely a duplicate of T83300 which is now fixed in newer daily builds. No word on if it will make it back to the 2.91 series yet.

As a normal user here I love the feature. I'm much better served with a snapping angle of 11.25, 15, or 22.5 deg than the default of 5. It works better for typical rotations I'd want to snap too (1/8th of a circle, 1/4, 1/6 etc). It would allow me to see exactly where I should snap too much more quickly.

I'm on Windows here so I only see the long load once (using a 1070). Switching to rendering mode after that (and even after restarting blender) is fast for me. You will have to wait and see if someone can repro the problem on linux and/or if the particular driver install for you is at fault.

This might be the Optix kernels compiling. They should only do so once, and should be cached by the driver after. @changkun (changkun) can you confirm if you have Optix set as the rendering device in your User Preferences?

Muting has not been designed or implemented yet for Geometry nodes. See T82546

This looks a lot like T82353 - I haven't checked because the files to download are very large - due to the fact that an invisible/disabled collection is mentioned here.

Modifiers for volume objects were only added for 2.91.x, not the 2.90.x versions.

Potentially a duplicate or related to T82351

There's a chance the data was written to the file in a corrupted state already. Blender crashing may have nothing to do with it. Blender won't be touching the file during its crash. Even if the crash happened during auto-save, blender will first write to a temp file and only replace the original once completed.

Note to other triagers: Doing either of the following makes the bug go away:

• Changing the sub-d levels to 2 instead of 3
• Disabling the solidify modifier

A few things:

• You need to apply the Scale on your Cube.
• You should use the "Even Thickness" option on your Cube's solidify

On your Shutter object, change the boolean modifier to "Fast" mode instead of the new "Exact" mode. Details about this new mode here: https://wiki.blender.org/wiki/Reference/Release_Notes/2.91/Modeling#Boolean

T82072 is a duplicate of T77868

We will have to wait for @Clément Foucault (fclem) or @Jeroen Bakker (jbakker) to chime in. It's a really odd bug to say the least but I also experience this on a ubuntu 20 VM I have running on the side.

I've seen this before myself and it relates to your graphics (either driver or hardware). In the blender folder there should be a file called blender-softwaregl, try running that and report back if it works correctly.

The modifiers are only in 2.91.x onwards (in the video they are using 2.91.0 Alpha). They are not in 2.90.x

Try adjust the "Clip Start" option in your viewport there (upper right in your video) to something reasonable like 0.01 m

Duplicate of T80974

Most likely a duplicate of T80005

It would be great if the UI team would come together and make the call to not disable panels in situations like this. This isn't the only place where things completely go missing if you have an option checked somewhere else in the UI. IMO it would be better to have the Panel grayed out instead instead of completely removed from the layout in many of these situations. Going further, having a small text message within the grayed panel explain why the panel is disabled could be bonus points but not strictly necessary.

Oh found this bug... hate to comment after it's closed, but KDE's taskbar also shows Blender using audio continuously. It's not a good look.

Ubuntu 20.04 works fine here when using the cifs variant of SMB, e.g //xxxx.file.core.windows.net/scratch on /mnt/scratch type cifs

You have a very high level 6 subdivision modifier enabled right there. Your 419 face icing object becomes 1,716,224 faces at level 6 (even more so since the solidify modifier is also adding more faces).

The version information above says "Unknown", this typically happens after building blender yourself. Is that what you did? If you did build yourself, can you confirm you built with Open subdiv support in your cmake settings?

Hmm, I'm not sure I follow completely. How would you implement the issue described in the original part of the report where I want to enable circle select only while I'm holding down the C key. Or are you saying that such a thing cannot be done within an addon?

Would the other, similar, options move to the Scene tab as well? Namely the SSR Half Res Trace and Shadows High Bitdepth settings.

The "Unknown" hash above could indicate that this is a custom build, rather than the official build. If it is indeed a custom build, was it compiled with Open SubDiv support?

This goes beyond Blender. Blender does not exist in a vacuum. The vfx platform exists not to limit a piece of software's dependencies because they feel like it that year. It's there so "studios" can piece together the myriad of software required for their pipeline to support dozens of artists. A studio of any significance today is probably using Maya, Zbrush, Houdini, Nuke, etc. and yes, for the most part, they are all pretty well standardized to the platform's requirements. Even UnrealEngine is moving towards Python3 to align for instance [1].

One more thing for completeness. It looks like you're using 2.80. Can you try 2.81 (or 2.82) available for download here (just unzip locally and run): https://builder.blender.org/download/

Yes, lack of hardware will make this difficult to address. In the meantime please try the following:

You're hitting 2 known issues as part of: T67744 (some mentioned as part of T47030 too)

1. Why it doesn't use the 30% you have set in render properties might be the primary bug here. Manually shrinking your initial dimensions to 2100x5400 works
2. It's odd why blender eats up resources and typically needs to be manually killed in this instance... still needs investigated I suppose
3. It may never be able to render at that 18000 dimension (100%) in any case. OpenGL GL_MAX_TEXTURE_SIZE limits on my AMD FirePro W2100 card is 16384 and I'm not aware of any implementation that allows higher than that.

Can you try pulling down from git again. A large eevee refactor was reverted due to some other issues. See if you have better luck after.

Agree with the comment about color due to said issues. Try a different shape (diamond?) as you'll never find a good set of colors to differentiate.

It was never removed and is in nearly an identical spot - Did you mean something else? If not just follow these steps:

• N (to open the N-panel just as before)
• Click the View tab (similar to the old View sub panel)
• Click "Lock Camera to View"

Yeah, I seem to hit it when I scrub the smoothness value back and forth and that usually triggers the above after some time. I sometimes have to stop the scrub and play with the cut # too and then go back to smoothness scrubbing (and repeat) for it to hit.

I can repro, I think, but it took a long time of playing around to hit it -- So sadly I don't have a better simplified set of steps but I do have a stack:

This bug is probably the reverse of what's stated. The "Knobs" object has its "hide_render" visibility setting enabled -- use the Outliner filter to show the render visibility state.