Sergey is rewriting Multires modifier in a local branch according to his weekly report . So you may want to submit the changes to each modifier separately?
Yes!! heck Yes!, Its a extremely welcome feature.
Use RNA directly for updating the handle types. This proved difficult because the points on the path didn't have a reference to the profile itself, which needs to be updated.
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce GTX 780/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 442.19
Mon, Feb 24
Current behavior is correct.
The problem is that an action can either store an undo step for edit mode (which doesn't include things outside of edit mode, such as the pose bone properties) or it can store the entire scene in memory (which doesn't include edito mode data). Deleting a bone changes both sets of data, so it cannot be properly un-done with just one step. This is a limitation that needs proper design work to resolve.
Sat, Feb 22
@Sergey Sharybin (sergey)
Anyway, I'll be happy with such optimisation, because mostly I work with static scenes and sculpts.
Fri, Feb 21
I can confirm that this happens in today's master, but I wouldn't call this a bug.
Wed, Feb 19
This is indeed a known issue.
Issue here is that for the depsgraph, it has no knowledge whether the modifier is disabled or not, so it keeps following the rules established by the relations generated in updateDepsgraph() modifier's callback.
@Adam Friesen (ace_dragon) the issue is NOT closed. Bug reports get merged if they are duplicates. If the main report is still Confirmed, then the bug is still open.
These issues should not be closed.
Tue, Feb 18
I was mistaken about this being also true of data transfer modifier. Custom normals from a data transfer modifier are being read correctly by a displace modifier. For that matter, they're also reading custom normals from a normal edit modified mesh appropriately. In fact, this can be used as a workaround-- make one mesh, likely non-rendering, to get the normal edit modifier, and a second mesh to copy normals via data transfer from the first mesh.
@Philipp Oeser (lichtwerk) poly normals are not custom/loop normals... The latter are for sure expected to be passed around in modifier stack.
This would break the old files that were saved with this modifier.
If you can make it configurable so that it doesn't break old files, I think it would have a better chance of being accepted.
This behavior is also inconsistent with the behavior of custom normals set via a weighted normal modifier. When that modifier is used, it seems to affect further modifiers appropriately.
Not sure about this, can you provide an example file where this works?
Mon, Feb 17
In this video you can see the speed reached in 2014 on Blender. Was the same test done in 2.8?
I don’t see any substantial improvements in 2.82.7
Playback is incredibly slow when the Subdivision modifier is applied to a mesh with animated shapes or bones.
In 2.79 and Maya it is tens of times faster.
Aaah! Sorry, I guess I just didn't understand bendy bones. Thank you so much!
Sun, Feb 16
I have the same problem. It occurs in Eevee and in Cycles.
I have been looking into this and it seems this has nothing to do with the shrinkwrap modifier. It is the result of changes to the bbone roll calculation.
Sat, Feb 15
Fri, Feb 14
140 faces and bevel modifier + subd lvl 2
Performance as in 2.80
Reconfirmed, still an issue
Simplified version of the first file:
The fact that the center vertices of the cylinder coincide with the top face of the cube is critical. Possibly related to T68144.