I just found out, that disabeling "outline" in the viewport shadeing dropover, makes the whole mesh disappear, what is my problem.
I can reproduce and confirm the behavior of the original report.
with the wire_frame_not_visible.blend file in blender 2.81 beta.
Wireframe and navigation Icons dissapear when selecting bone in editmode.
I might have found a related problem in Blender 2.81 beta on Mac OS X, Graphic Card: Intel Iris Graphics 6100. When selecting a bone in Editmode ALL MESHES disappear (and the viewport navigation icons as well)
Wed, Oct 16
Tue, Oct 15
I agree that might be related T67831. I cannot reproduce it because I don't have macOS.
Mon, Oct 14
That *could* be some issue with your hard drive (generating some .blend file corruption)? But that’s really a wild guess, chasing that kind of weird bug that only happens on one machine can be very long and hard.
Thu, Oct 10
Can you try macOS Catalina? Blender 2.80.75 seems to work fine on my hardware on Catalina.
Wed, Oct 9
Hi, don’t know every much about code and I'm fairly new to blender, can anyone help me out with an explanation on how to fix this issue or which blender scripts to change, I'd very much appreciate it. Thank you!
I'm not sure about flushing the queue where you suggest. handleTabletEvent() does not seem to modify the event in the queue, it just sets some tablet parameters (pressure, tilt) in some window context object, and then presumably some other code uses that info when it comes to processing the event. For drawing, then, you want the latest tablet info available when the event gets processed or else you're always using old pressure data. The only instance where you don't want tablet data smashing is on the leaving proximity event because it leaves tablet mode, and no drawing is going to happen anyway.
We are aware of many issues on MAC OS, but unfortunately we have no developers with this setup to investigate and reproduce the problem.
When Blender supports Vulkan, many of these problems will likely be solved.
can conform this fix works also on astropad and duet.
thanks @Tim Lesher (tim) Carroll (codrus) for this!
@Brecht Van Lommel (brecht) Van Lommel (brecht) is there any reason why this fix can't go in master?
This morning I downloaded the most recent Daily Build, version rB0812949bbc3d and found that it had the exact same problem. I tried launching it using the Terminal with a --factory-setup, still crashed right upon launching.
Good catch. I was looking for something like dispatchEvents() yesterday but couldn't find it.
Tue, Oct 8
@steve miller (winnertakesteve) yes I also am using Edit Mode and Eevee together here. I will do further testing to see if the recent fix has affected this issue or not.
This may or may not be an acceptable fix, but adding dispatchEvents() when leaving proximity in handleTabletEvent() flushes out the event queue and fixes the issue for me in both grease pencil and texture paint modes:
also having this issue. can't seem to make anything 100% reproducible, but the common factors seem to be eevee in edit mode, and trying to either perform vertex selections (such as clicking 'L' over a mesh) or connecting image nodes to a principled shader.
I can confirm that if I comment out tabletPoint and tabletProximity in WindowCocoaView, the problem goes away. The mouse up messages have tablet information so pressure get released as appropriate. This was just a test; those events are important for tablets with proximity sensors. Also, I found that later events (like window deactivation) were showing tablet events, which would clearly not be the right thing.
This is how macOS works for all apps. They are not launched in an environment that reads .profile and similar.
I've got a partial answer for what's going on -- will try to pick this up again tomorrow night, but thought I'd pass on some notes.
The same issue happens in the release version of Catalina with Sidecar and an iPad Pro/Apple Pencil.
Mon, Oct 7
I am also experiencing the same issue, even after the above patch.
I haven't noticed it so far with my Intel laptop, but I'm not using Eevee much on it or it may be AMD driver specific.
Fri, Oct 4
This happens consistently on my 2015 MBP when moving from the larger 2540 x 1440 to the laptop screen (secondary display). It is especially annoying when I return to the studio in the morning after having scaled down to laptop size and the interface does not expand properly when I drag it back to the primary display. As noted in all of the above comments, it is the responsiveness of the interface scaling that's a problem. It's been a consistent issue for all of the 2.8x builds.
As of version: 2.81 (sub 13), branch: master, commit date: 2019-10-03 21:03, hash: rBfbc096cf075b
I disconnected the noise texture color from the principled BSDF Base color, to make the bug show when opening the file.
Thu, Oct 3
We are aware of many issues with MAC OS, but unfortunately we have no developers with this setup to investigate and reproduce the problem.
Changes are constantly being made to improve viewport peformanse, and it is quite possible that this regression will be resolved in the next builds.
@Clément Foucault (fclem), any idea why this is happening?
Wed, Oct 2
I think we need someone on MacOS to reproduce...
Tue, Oct 1
More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.
Mon, Sep 30
Having the exact same behaviour as @Addison Miller (seaside98).
An additional element might be that my secondary monitor (Dell U2715H) is not supported by macOS High DPI scaling. Just dragging the window to the second screen and bringing it back solves the issue.
But removing the secondary display makes blender unusable
Sun, Sep 29
Fri, Sep 27
Operating system: Darwin-18.7.0-x86_64-i386-64bit 64 Bits
Graphics card: AMD Radeon Pro 580X OpenGL Engine ATI Technologies Inc. 4.1 ATI-2.11.20
Thu, Sep 26