For developers working at the Blender Studio to organize Blender bugs and tasks reported by artists.
I think I can still reproduce this issue, eg. changing the "Dress" property in hailey.blend above. q_q Do I re-open?
Mon, Feb 24
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.
Fri, Feb 21
Resolved by committing 4c30dc343165a643e2173a055ed2aca3137991a5
Wed, Feb 19
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 bee far more efficient than evaluating all of them in a single thread, without atomic ops at all).
Tue, Feb 18
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.
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.
Mon, Feb 17
Worked: Maybe a month or two ago?
Sun, Feb 16
It's been pointed out to me this may be a duplicate of T56635, but that one was closed as resolved. Maybe this should be merged into that one, and that one be re-opened? I'm not 100% sure it's the same issue, but definitely seems very similar.
Thu, Feb 13
Wed, Feb 12
Tue, Feb 11
Mon, Feb 10
I can confirm the problem.
Fri, Feb 7
Tue, Feb 4
Sun, Feb 2
Wed, Jan 29
@Germano Cavalcante (mano-wii) please remember to add the - it worked in 2.79 information in the original bug description. A fully triaged report should have all the required information to fix it in said description.
Tue, Jan 28
I can confirm the bug.
It didn't happen in blender 2.79
Jan 20 2020
there are few suggetions for people that has this bug:
For example you have already made model with hires modifier and you want to use Apply Base on it. Like this one
If you just press that button it will ... destroy your sculpt -
But! If you first sculpt something on model ... something, whatever it is
And only then press Apply Base - everything will be ok.
This is after i pressed Apply Base. as you see all sculpt data is on it's place. But topology of mesh is changed. Probably when blender activates sculpt mode it is not load all the sculpt data or... something like this.
This is not happening for 2.82 since we are in bugfixing only phase now, and this is a bigger change.
Jan 17 2020
This was resolved by 6eaf51ef3e5b.
Now we have to decide if we include this in 2.82.
Jan 16 2020
It is better to discuss this in a design task: D6603
So closing this as it is not a bug.
Jan 15 2020
I agree with adding offset in bottom part.
I don't think we should move the marker region to the top. It would make things inconsistent, but it's also a workaround exposed as feature.
I think the best solution is to offset the strips so the bottom ones aren't always covered. Or, make it possible to scroll past the bottom layer.