System Information
Operating system: Linux-5.8.18-300.fc33.x86_64-x86_64-with-fedora-33-Thirty_Three 64 Bits
Graphics card: GeForce GTX 970M/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 450.66
Tablet: Wacom Intuos 4
User Details
- User Since
- Sep 14 2008, 10:31 PM (713 w, 6 d)
- Roles
- Administrator
Today
Yesterday
Can confirm, will check.
Fri, May 20
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.
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
Looks like T98128: Regression: EEVEE: Default Cube is black on Intel, will merge reports
@Clément Foucault (fclem): mind checking?
yeah, bug
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
Thu, May 19
@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?
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
The data is usually removed alongside the modifier.
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.
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?
Wed, May 18
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...
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...)