anyone knows, has a hint, why this handler-render crashs blender?
# you have to run this script - Alt-p
# to insert the function into the render-handler
# then run the render-animation F12 to see
# the modification of the plane
#
# with the running render-process, the memory usage gets higher
# and the ui will be corrupted -
# You have to quit blender (ctrl-q) and restart to get it working again
#
# Anyone has an idea what is going wrong?
#
import bpy
import random
def myFunc(scene):
plane = bpy.data.objects["Plane"]
v = plane.data.vertices
v_count = len(v)
for i in range(v_count):
z = random.random() - 0.5
v[i].co[2] = z
scene.update()
bpy.app.handlers.render_pre.append(myFunc)
thats the script inside this little blend-file with a subdivided plane.
It crashes blender 2.58.1 r39207
and blender 2.59 r39349
both for linux-64bit.
ATTENTION! The bad thing is, after restarting blender
i always have to re-load the default settings (“Load Factory Settings”)
to get a full working version again. This is like the quit is writing some
destructed things out to the ?startup thing.
I can reproduce the corruption with this blend-file, but i have no idea
what kind of corruption it is. Changing the position of vertices?
@atom,
thanks for the try,
i have used “plane.data.update()” too before and it did crash too.
It looks like it needs some time to run. For example if you do not
check the error-output in a console (that is starting blender out of a terminal
to see those messages) it runs the render of the 100 frames without crash.
But at the end some functions (mouse-functions) are not working any more
and after another run or creating a new 3D-view window suddenly the
menu-line disappears. With more runs i got a kind of memory fault and blender crashed.
It looks like something is wrong when modifiying the vertex-location in the render_pre handler. The same code without the handler runs without errors again and again.
The reason for this code was, i saw the posting about running “game of life” in blender and wanted to give it a try. But then i noticed running it, it crashed blender and the stripped down result was, that every mesh-vertix location changes eat up the memory and crash blender. (looks like something is overwriting the heap?
You are shure, there are no error messages in the windows-version? Did you check the memory display when the video-render is running? (its in blender in the top-menu-line, where the number of vertices etc. is shown)
Oh, I thought you meant Blender was crashing, my bad.
With a little error protection, I had some luck with this modification to your code.
import bpy
import random
def myFunc(scene):
plane = bpy.data.objects["Plane"]
if plane != None:
v = plane.data.vertices
if v != None:
v_count = len(v)
if v_count > 0:
for i in range(v_count):
z = random.random() - 0.5
v<i>.co[2] = z
scene.update()
bpy.app.handlers.render_pre.append(myFunc)
Prior to these changes, I was seeing the python crash message you mentioned.
I have seen this kind of error before, in some of my frameChange events. Your code is not crashing, it is some part of the Blender interface, typically. But the operations in your code is causing some unexpected state that the GUI code craps out on.
My guess is that the [I]pre-render event is not rock solid yet. Imagine what happens when the event fires unexpectedly because your code updates the scene. Upon re-entry to the event processor bpy is in an unexpected state so operations fail or return nothing. I often put is_busy flags inside event processors to block unexpected events.
@Atom: thanks for your help, but the blender 64bit-linux version still crashs.
Blender-2.59 crashs very soon after 2 to 3 rendered images, while the older
blender -2.58.1 runs the whole rendering but shows error-messages after
10 to 20 rendered frames and at the end the menu-line of the 3Dview-window
disappears and console messages show some error in some py-gui scripts
(something about lost context …)
So i did it the other way round:
and the little blend-sample (blender-2.59)
and there was one funny error too - i used the duplication at vertices
and the whole plane changed its level for a few frames while the duplication
set to object (like in the sample-file) rendered without such hickups.
Ah, I see what you did. You just manage the rendering directly for yourself and forget about the pre_render event. Which does not seem to work reliably anyway. Another option might be some kind of bake which I had to do in one of my scripts to solve this kind of crashing problem.
yes, baking the movement of vertices would be another option. But for such things its a waste of memory and performance. The AnimeAll addon is a good example for such a kind of recording …
The only backdraw is, the rendering works only for single images and one need another blender-run to import those images into the video-sequenc-editor and generate one video …
