I have extensively customized Blender's interaction, and I feel I have a fairly good insight into the Input Editor ('Engine"), and also some minor insight of what might be happening under the hood.
Setting as incomplete until the additional information is provided.
Started happening after rB8f0dc3cef6c3: Fix T50052: bpy.utils.unregister_module doesn't unregister classes of….
Seems like ANY python thread might crash when RENDERED is being turned off. In my test I've simply added an operator that spawns a thread. Not using a renderengine callback(callbacks are empty). It crashes.
addon_thread_from_operator_crashes_on_rendered_off.7z Just execute the 'Test Start Thread' operator and start pressing Shift-Z(using Test engine or Blender doesn't matter) - it crashes after a few iterations.
I can confirm the issues with the latest builds on Windows 7 too.
Win 64 Build from 14th November fc9fa07 doesn't mess up on reload.
From those reports it seems you have no Intel driver running. Grab it here:
@Steffen Mortensen (stifan): Thanks for identifying the problem! Fixes committed to master now :)
Had the same problem, and really couldn't make sense of the error. But i found the solution!
The issue you are having is not actually related to shape keys, but rather the fact that the Mesh Deform modifier only works with manifold (closed) cage meshes, while your "head" mesh is non-manifold. The bind will succeed, and you may be able to get the result you are looking for, simply by closing all holes in the cage mesh.
put on new patch (lyapunow + some extra mandelbrot sugar [called "bulb"] ;)
-> here -> http://maitag.de/semmi/blender/lyapunov/example_images/start17/patches/
Fri, Jan 20
I wrote a simple OpenGL info program. @anatoly techtonik (techtonik) please run this and attach OpenGLinfo.txt it generates. That will give us more info about your system & help us decide what to do.
Verified the issue was fixed
Blender version: 2.78 2017-01-19 b76dbf5
GPU: AMD Bonaire
Like it was said, check if the possible solutions mentioned in the 2.77 release notes worked for you.
I don't see how this is an underlying issue with the layout engine. Using a .active or .disabled tag, assigned to a certain layout block will affect all of its assigned properties. So using two different UI blocks is a proper fix.
Panorama types are only available in Cycles. Please read the Blender manual: https://www.blender.org/manual/render/cycles/camera.html
If a bug report doesn't follow the guideline can be closed. This is a place for bug reports mostly, not for user support.
Thomas, care to look at it?
Please follow our submission template and guidelines next time (we are at the very least missing all your PC specifications here, GPU, driver, version of ubuntu etc. etc.).
And please check your hdd, SMART data and all (unless you do not have any issue with other apps re. hard drive), that kind of thing sounds a lot like dying hdd to me…
Thu, Jan 19
Hi Joey, can you elaborate on "better options" Im working on a network rendering addon for blender at the moment, would be nice to know what the plans are regarding this feature.
Chris Lee's screenshot shows the abrupt falloff clearly,
and I attest that the problem persists in recent builds (e.g. Jan 18th 2017) of Blender 2.78,
and even on the Experimental Branch build of Jan 15th. (Mac OS)
Is the mesh generated from a script?
Make sure you don't use any of the addons, start blender with --factory-startup command line argument to be sure. Also ensure you don't use any handlers (pre/posr render and similar).
I can confirm the issue with your file, but I can't reproduce it. How did you get a polygon like that? Looks like it has issues with vertex order.
Few things here:
- That log is not reporting a crash at all, afaict blender is closing OK (error reported are from python, maybe some wrong order in Cycles RNA classes unregistering, or something else - 'destructor' of classes in python are notoriously unreliable :/ ). Anyway, this is no crashing.
- We would for sure need a file to reproduce the issue, though in that case if error is not even consistently reproducible with a same given file, it sounds a bit like a wild goose chase.
- Nonetheless, we do not accept to privately handle cases of non-open files, nor any kind of NDA etc. That kind of thing is not compatible with an open project development.
- Random crashes could also be caused by mere memory allocation fault. That would depend on amount of RAM, amount of available RAM, amount of RAM fragmentation, etc. E.g.: do crashes happen immediately after start of computer, or only after hours of work?
- Other thing with very complex files that can go wrong in current blender, especially if some physical simulations are involved, is is concurrency between rendering process and usual UI refresh - Please try to lock the interface during render (little lock icon next to the display selector, in Render panel) and see whether it crashes still happen.
There's very little to go on here, try using something like process monitor ( https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx ) to see what's going on.