For developers working at the Blender Studio to organize Blender bugs and tasks reported by artists.
Fri, Jun 26
Wed, Jun 17
Tue, Jun 16
Multires Simple Subdivision type is fine
Ok apparently instead of using the custom shortcut I mentioned, this can also be more easily replicated by just using undo, exiting sculpt mode and entering sculpt mode again.
The same effect is then suddenly visible.
Fri, Jun 12
@Germano Cavalcante (mano-wii) I just tested it on another computer as well and I can reproduce the bug with the outlines steps.
In your file you didn't make any changes to the shapekey. You need to model or sculpt changes on the base resolution (level 0) since the multires subdivisions are not changing the base and therefore don't affect the shapekeys.
Thu, Jun 11
I'm confused. I don't know where to expect to see the bug.
I'm testing this file but shortcut only enables or disables the x-mirror option.
Even leaving and returning to sculpt mode I don't see the bug.
Has any step been missing in the description?
Wed, Jun 10
Jun 6 2020
Jun 5 2020
Confirmed, this is related to new undo in general, not only recent commits in master (i.e. likely also affecting 2.83...). Only workaround for now is to disable new undo in user preferences.
May 12 2020
Apr 10 2020
I think we can close this task because now we have solved the problems with ugly corners of stroke sand to get a even point distribution, we can use the simplify Sample mode.
Mar 23 2020
Mar 22 2020
Mar 20 2020
I can confirm that update is still not always working as expected, also with file from T70350. No more warning though, afaict.
Mar 18 2020
DO WANT this in the nignt-build
Is simething wrong with it? Because it is still not in master.
Mar 13 2020
Apply Base, Subdivide and Reshape should now be fixed (rBbc0a0cdf171).
Feb 26 2020
I think I can still reproduce this issue, eg. changing the "Dress" property in hailey.blend above. :( Do I re-open?
Feb 24 2020
The selection sync between bones and dope sheet is a known weak area of Blender, so I'm closing this as a known issue. Don't worry, I've added this to my list of weak areas of the animation system so that it's not forgotten.
Feb 21 2020
Resolved by committing 4c30dc343165a643e2173a055ed2aca3137991a5
Feb 19 2020
Please stay away from atomics in RNA. There is indeed some overhead in RNA system, but it does not affect how scalable code is with the number of threads. Once you add atomic the scalability goes to nothing.
I expect it can improve performance slightly in production (but not enough to really matter). There is overhead to having more depsgraph nodes and relations. The only way you would have that many drivers on an ID in practice is bones, and we can group those together (and also have to for drivers to work between bones at all).
Not sure performances is a real issue here (atomics are slower, yes, but RNA also adds a fair amount of overhead, and all in all, I think I’d expect being able to evaluate tens of drivers/animation curves in parallel, even if those involve some atomic ops, would be far more efficient than evaluating all of them in a single thread, without atomic ops at all).
Feb 18 2020
I extended my comment above a bit, to explain why I think this is the wrong level to add thread safety.
@Brecht Van Lommel (brecht) issue with bitflags in RNA is that from RNA side they look like different properties, but they actually affect the exact same value. So idea would be that default RNA setter would set those bitflags with atomic operations yes...
I'm not sure what it means to make the RNA access atomic, how would that be implemented, manually for each property? If so, there are many of them and taking that into account for every new property sounds fragile. I'm also not sure to what extent writing a char or short could conflict with an adjacent variable.
After looking into this with @Sybren A. Stüvel (sybren), we think the random failures are most likely due to a threading issue, where two threads are evaluating the viewport and render visibility driver for the same object in parallel. These two properties are stored as bitflags on the same integer, so writing to them at the same time is not thread-safe.
Here is a fairly simplified file and video:
I didn't want to simplify it too much further since it feels like there is a correlation between scene complexity and how easy it is to reproduce the bug. (the more complex the scene, the more often the bug occurs) - even at this level of complexity, it seems that changing the values "fast"(multiple times per second) is necessary to trigger the bug.
When the armature is not a proxy, the issue is still present, but the above warning is not.
Feb 17 2020
Worked: Maybe a month or two ago?