Can confirm, will check.

This should work for dedicated F12 renders, no? (this works on my side)
It is just that overscan does not work for viewport rendering, see T91277: Eevee viewport rendering Overscan doesn't work

Same thing did not crash before rB8f9f65bc29fb: Allow overrides for cloth, collision and force field properties.

What I meant was that since rB5596f79821ca: LibOverride: Massive edits to 'editable' IDs checks in editors code., you cannot add the collision modifier (or any modifier really) to the overridden object by default.
You first have to make the overidden object editable from the Outliner.

CC @Sergej Reich (sergof)

This crashed in 3.1.2, yes, it is disabled now though, think this is intentional, will double-check.

Making this High Prio since it is a regression

CC @Jeroen Bakker (jbakker)
CC @Clément Foucault (fclem)

Looks like T98128: Regression: EEVEE: Default Cube is black on Intel, will merge reports

@Clément Foucault (fclem): mind checking?

yeah, bug

Caused by rB80859a6cb272: GPU: Make nodetree GLSL Codegen render engine agnostic

Seems something changed in regards to normalmaps on scaled objects, the issue goes away if object scale is applied.
Still looks like a bug, will check

Caused by rB1aa54d4921c2: Make rigidbody simulation handle animated objects gracefully
I will dare setting this to High prio since we know what caused this and it basically makes using substeps in combination with forcefields useless.
(but prio could be lowered again since rigidbodies lack a dev atm)

Can confirm, will check

So this is just a conflict as @Pratik Borhade (PratikPB2123) said.
Please change the shortcut of either to something else (or disable the shortcut for object.transfer_mode) and you should be fine.

Can confirm, broke between 17eb8a9cebd5 and a5644f9a28ea

@Chris Clyne (lateasusual) : please submit a Diff https://wiki.blender.org/wiki/Process/Contributing_Code, chances are better this gets attention then

Will confirm then

Got an example .blend file to reproduce?

In T98255#1361323, @Scurest (scurest) wrote:

Try turning the "Image Search" option off on the import screen.

https://docs.blender.org/api/3.3/bpy.types.Mesh.html#bpy.types.Mesh.validate_material_indices will also correct invalid indices, so the "corruption" in your mesh is that there are poly that have materials assigned that dont exist.

Will confirm for now (since I cant make sense of it atm).

Looks like this is actually the geometry nodes modifier being calculated.
If you use a Realize Instances node just before outputting the geometry, the lag goes away

Caused by rBe8dc82311d1a: Fix T96145: GPencil eval data not updated correctly

The data is usually removed alongside the modifier.

In D12568#403116, @Julien Kaspar (JulienKaspar) wrote:

This does not work in an intuitive way. With this patch, the pressure sensitivity will live update the strength of the stroke until the pen is lifted and the operation is done.
The issue is that the act of lifting up the pen will revert the pen pressure back to 0 and undo the stroke entirely. This makes the brush unusable.

Ah, we had this before...

This has been reported again, see T98249: Bloated mesh data example (multires CD_MDISPS hanging around without a multires modifier) and actually I think we should reopen this (even if only as a Known Issue)

So we will need to find a way to reproduce this borked multires data hanging around

Hm, there is an unnamed customdata layer on the loops (seems to be multires data).

Hm, can confirm, will check

Hm, cannot reproduce actually.

In D11537#403092, @Frederik Steinmetz (SpiderguyF) wrote:

Silly me, no it's not. Just the possibility of occasionally creating invalid connections, but that's fine, just do it manually when it fails.

T98247: Regression: Shader To RGB not displaying textures might have the same root causes

Can confirm, probably the same as T98245: Regression: Missing viewport update when shader to RGB is used in nodegroup though.

@Andrew Woods (cga558b): then please report this over at github

Why BF Blender 2.90?

Good to hear! Will close then

Cant spot the fault in the geo nodetree either. Weird.

Yes, this has been reported before, see T93381: 3D viewport sub-header ignores setting of no header after reopen file., will merge reports.

Can you provide the example .blend file where this happens?
Have you tried the same with using GLTF2? (nowadays, this seems to be the much more stable option to use in regards to exchange formats).

sorry I haven't got time to provide more info.

Can confirm the behavior.

It seems the original author prefers to track bugs on github?
https://github.com/alessandro-zomparelli/tissue/issues

I can only guess it worked with less massive memory consumption in 2.92.

This is basically just a warning that you can safely ignore it seems.
(at least I think you can).

This is from the debug output which might be interesting

Open Image Editor in Blender tab to find current render result

are we talking about the Rendering workspace?
or just turning the 3DView into an Image Editor?

@Bastien Montagne (mont29) : setting this to High Prio (even though it is a bit dated), but it is just something not so nice to have...

In T98225#1360633, @Hasan Cem Safa Ece (Zaib) wrote:

I've actually returned to a previous autosave, but would like to find a solution for when it occurs again.

Can confirm.

The UI could need some love here, agree (this is a bit involved though since the operator can act on many different types, not just meshes, metaballs, fonts, ... -- plus it also accepts mixed selections of those...)