Thu, Feb 8
Since the commit rBe0597baed57f Carve library was removed from Blender. Since these boolean problems are related to issues within the library, the task can be closed.
Wed, Feb 7
Tue, Feb 6
Sun, Feb 4
Workaround: I'm using v2.79 and experiencing same problem as described, where regardless of which monitor I was using as my main display, Blender was always opening up in the secondary monitor. I forgot to do a diff on the startup files, but this is how I worked around it: In Windows 10 I have a single video card with multiple monitors, but I think the problem is in the settings somewhere and doesn't matter the setup:
- I had to right-click on the Desktop and select Display Settings.
- Under "Multiple Displays" I changed it from "Extend These Displays" to "Duplicate These Displays"
- I opened Blender and with it selected in the primary display I Saved Startup File and then Close Blender.
- Under "Multiple Displays" I changed it from "Duplicate These Displays" back to "Extend These Displays"
- Reopen Blender, and it opens in the primary display as selected.
If I get a chance, I'll try to experiment to see exactly what is happening here, but in the meantime I hope this helps!
Thu, Feb 1
Just as a clarification, cmake silently removed the runtime dlls for 2.79a, i didn't do this deliberately, This patch retains the old functionality (include all needed dll's), and no longer silently fails when build with newer cmake.
If this never impacts users (only CMake maintenance), then I don't see anything against applying the patch.
actually it does, i accidentally shipped the 2.79a-rc without the runtime dll's due to this issue, just nobody has noticed it yet...
I brought that up earlier today on irc, the BF stance was blender should work on a clean install, no extra downloads needed, so we're gonna keep shipping the runtime dll's (even though they ballooned from 3-4 to about 45 files)
@LazyDodo (LazyDodo) from your last comment I don't see why we wouldn't apply this patch (if it really does work as intended).
Wed, Jan 31
@Hans Chnuspi (chnuspi1234) : Hi Hans, thanks for your video, now I understood!
@Hans Chnuspi (chnuspi1234) : thx for making that clearer :)
@Alberto Giorgi (AlbertG) : left hand side of your screenshot the face is also 'back' (you just see right through in wireframe)
reg. missing faces: I think that video makes it clear?
I believe you have been tricked by an optical illusion - I hope this short video clarifies it for you :)
This patch description is quite vague,
Tue, Jan 30
Hi Philips, thanks for your answer!
Mon, Jan 29
I am not sure if I understand correctly:
Sun, Jan 28
Tue, Jan 23
I have the same issue. Blender starts up with a white screen. I have an Windows 10, 64bit, intel i7 (1.99GHz), 16GB RAM, NVIDIA GEFORCE. I don't know much about computers, but the way that I was able to get Blender to work was to right-click on the start up icon, and choose "Run with Graphics Processor > integrated graphics". I don't know what implications this has on renders, etc., but it is the onl way I could get Blender to work.
similar to T53690
Jan 14 2018
In Linux or macOS i would make those symbols local in the exports map.
I suggest using a windows technique to archieve here those symbols are local.
This would avoid clashes.
Jan 13 2018
Problem has not been fixed for me. It still flickers and stops responding everytime i click something and crashes whenever i minimize. I'm using latest 2.79 and a Radeon Vega 64.
Jan 9 2018
cannot reproduce here either, adding Windows tag
Jan 6 2018
After some test I can't reproduce with one monitor in macOS, so probably is only a problem in windows systems.
note that I only tested this with one monitor, still possible this happens with two (but report mentioned this also fails with only one monitor)
A bit speculative, but tagging as windows until someone can reproduce elsewhere...
Jan 5 2018
I dare to close this as you mentioned this is a Windows related problem regarding the Fall Creators update and I think considering the limited resources it is out of scope finding a workaround for this in blender.
Hopefully Microsoft will provide a solution rather than later.
If someone thinks its an easy fix though: feel free to reopen :)
Dec 25 2017
this might help it uses same ntrig pen
Dec 24 2017
Thanks for looking into this. I'll add some more details to try and answer the questions above.
- Does pen pressure sensitivity work in any other apps (e.g. Krita, Gimp, etc.)?
- Is this limited to any specific part of Blender (e.g. Grease Pencil, Sculpt, or Image/Texture Paint)?
- Have you tried searching for whther anyone else has been encountering pressure sensitivity issues with the Surface Book? At least for earlier versions of these, there have been cases where there have been problems using them with various apps.
Dec 13 2017
Nov 28 2017
This is still broken for me but it usually doesn't start right away. When it starts, even my mouse won't work and it also affects texture and curve drawing. If I disable pressure sensitivity then I can make brush strokes again.
Nov 24 2017
Did a quick check here on linux (which is utf-8 unicode system since… ages), with non-ascii chars in file name, and it works perfectly well.
Nov 14 2017
After seeing this I tried installing photoshop trial and it indeed fixes the issue for blender (and Gimp, and Inkscape)
Oct 16 2017
Right. Just to clarify, I agree that it's probably a good idea to just hide these completely for playback.
If one wants to debug rotations, it can still be done by going through frames manually. Or in a whole bunch of different ways :)
Also note that I'm speaking about all manipulators, not just transform manipulators. Can't really see a good reason to keep them visible on playback (maybe auto-keying spot light moves during playback? Does anyone do such things?).
Indeed - it may be a good idea to just hide them to avoid the performance hit and also allow animators to see the scene with less clutter (though there are also the rigs visible still).
On the other hand, I can also imagine how having these visible might be useful in some (rare?) circumstances (e.g. debugging rotations).
Should be easy to fix, however updating manipulator position on every frame may mean some frames less per sec. Maybe we should hide manipulators during playback? We could also cache coordinates but seriously doubt that would be worth it :S
Confirmed (gp-branch from 11 October). This only seems to happen when playing back the animation (Alt-A) but not when scrubbing.