- User Since
- Aug 1 2018, 11:24 AM (155 w, 3 d)
Feb 18 2021
It's really strange, I had to try several times today to reproduce it. There is no system console error, only a message shown in the status bar and python info:
Feb 16 2021
Feb 3 2021
I have the original file, but cannot share it here (it's a commercial product). I suspect that the shape key table is broken because I deleted faces not visible in the final render (to reduce poly count of an already heavy scene) and causing z-fighting issues with other geometry in close proximity when far away from the world origin (other issue in another task). I wouldn't care shape keys not working if I delete related faces/vertices, but would expect that it does not crash blender when entering edit mode.
Feb 1 2021
Jan 11 2021
Thanks a lot for that code! It really solved the problem. I'm very interested under which circumstances the parent-child relationship is maintained to a linked parent after overriding. I'm not aware that I have done anything differently to these two objects than to the others. And the UI lacks any kind of information if the parent is in the same file or in the linked file. Perhaps some more documentation on the "under the hood" of linking and overriding would help a great deal.
Jan 7 2021
Jan 3 2021
Just happened to me now after switching to wireframe
Trying to find out more I noticed that the trouble starts when I use the shift+s pie menu to snap the root of the overridden objects to the 3D cursor. For some reason the "Offset" was on in the "adjust last operation" menu, but I never noticed as the menu was always collapsed. I have no idea how I can fix it afterwards or how I can access that "offset" property to turn it off per object, other than clearing the parent and parenting again? If this is not a bug it is at least a usability problem. An info in the "Relations" section of the object properties would be the minimum I'd expect, unless I too ignorant and don't know where to look at :)
I changed the task description, as I could not reproduce the crash caused by the nvoglv64.dll, and this is perhaps unrelated to the other issue with library overrides. If I find out more to the nvidia bug I'll post it seperately. The attached blend files are already greatly reduced in complexity.
Jan 1 2021
I experienced the same quite randomly. I'll run debug mode to see if I can catch some hint.
I had a similar problem with an addon that uses collada for importing geometry on my Windows 10 system. Works with 2.83 though, haven't tried 2.90. I thought the addon was broken, but it looks like it's a Blender thing.
Nov 19 2020
I just recreated a very basic scene with only one emitter (default cube) and another subdivided and displaced cube as particle object. To me it seems that somehow it is related to change the emitter object on a mesh level and baking again, e.g. deleting a face, bake again, safe file, render. But I'm not 100% sure, this seems very erratic.
This basic scene crashes immediately upon opening and rendering (Ctrl F12).
Nov 18 2020
The hint with the particles helped a lot to reduce the scene to a minimum and get a closer idea of what is causing the trouble. It only crashes if disk cache is unchecked, but if I bake to disk cache it does not crash anymore. Anyway, here's the file:
Nov 17 2020
Nov 13 2020
Nov 12 2020
Oct 21 2020
This was very helpful, I could fix the console errors and could also fix the console errors in the original file. However, this did not fix the problem of the animation being different in the viewport and in the render. I started simplifying the scene bit by bit and found that the problem was gone after I deleted an armature parented to an object of another armature. I still need to figure out the exact reproduction stepts, as reproducing it with simple armatures and objects did not result in the same problem.
Renamed the task, as the other problem seems to be unrelated to the errors thrown by the system console. I still need to investigate why exactly the animation looks different in the viewport than in the render. In the example file this issue does not show up.
Oct 20 2020
Aug 29 2020
Mar 9 2020
Feb 12 2020
Feb 4 2020
Oct 17 2019
Feb 6 2019
I updated to driver version 188.8.131.5272 (from Lenovo), and the only change is that Blender crashes before I see the default workspace (today's build). Currently I'm fine knowing that I have to turn off conservative morphological anti-aliasing to make Blender work. It also seems that it is turned off by default now anyway, and can only be changed manually for a specific application. After some search across the internet, this "feature" seems to be a problem for many applications and games since 2015.
Jan 31 2019
I could fix the scene by deactivating adaptive domain, applying scale to the domain, and reactivating adaptive domain. Seems the the smoke sim does not like scaling other than 1.
Same here on Win 10 Home 64, GTX 1070, with today's build.
Ok, so far I tried it with earlier versions, and it worked without crash up till 2019-01-19 Hash b0dee09a6d55, which was the latest I had on my hard drive before 2019-01-29 Hash a1ae04d15a9f. Updated Nvidia drivers to 417.71, no success.
Downloaded latest from today (8c8979067490) and...it doesn't crash anymore!
Jan 30 2019
Jan 10 2019
I just wanted to report that I reopened the scene today and it renders fine now. Same blender build, same GPU driver. Not sure what fixed it. Perhaps a reboot or restart of Blender.
Jan 4 2019
Nov 29 2018
I found a solution to the problem, found in another thread:
Go to the intel HD Graphics Control Panel 3D Settings and turn off conservative morphological anti-aliasing.
So this seems to be an intel problem.
Oct 25 2018
Oct 22 2018
Awesome, also fixed it for me on Win10!
Oct 19 2018
Windows 10 Home 64-bit, GeForce 9600 GS 768MB (NVIDIA driver 342.01, which is the latest available for this card)
OS up to date.
Aug 17 2018
Awesome, this fixed it for me (trying 77e1942e0e1).
Thanks a lot!
Aug 1 2018
Coming from T56193 to this one (which seems to be similar). Exactly the same behaviour.
When starting blender with --factory-startup from the Windows 10 commandline (running as admin) I see the following in the command prompt after the crash: