(At time of crash) CPU Usage 99%, Physical Memory 53%
(Blender Console after crash) “write exr tmp file, 3600x227, C:/tmp/OHWPLH-001F.blend_Scene.exr”
I don’t understand “exr”, “write exr temp file” and “Scene.exr”.
(Blender) Buffers: Activated
The total size of the still image I am trying to render is 3600x5400 pixels. I have created 25 cameras each rendering an area of 3600x227 pixels. 23 of the cameras render and composite OK, but 2 of them always crash.
Is there anything more I can do to get the 2 renders to work?
The 2 renders in question crash even when the render Parts/Tiles are set at a high number.
When .blend file is first opened and before doing any render, there is this console message, “Error, region type missing in - name:”", id:8". I don’thave any idea what this means. Could this be causing the crash?
It sounds like your machine is running out of RAM when rendering, if your running a 64-bit OS then get hold a 64-bit version of blender and try rendering it out again. Although I suspect your machine doesn’t have enough RAM or your machine is 32-bit in which case it won’t be able to use all 4GB’s.
This message comes out when you have enabled the “Save Buffers” and the “Full Sample” option. Blender saves the rendered image temporary into exr (lossless format) and then makes some calculations from it. Try disabling the FSA, but I doubt this caused the crash, please give more info about the scene, that you try to render.
on 32bit blender (or any other app) can use 2gig, and even then you have memory fragmentation which can result in less then 2gig.
I heard memory fragmentation on windows is worse then other OS’s which is why people are using malloc replacements like jemalloc and hoard.
After working at this all day today, I finally got the two cameras to render without crashing, but am not exactly sure why.
The scene has 1184 objects with 2.92 million verts. I set up composite nodes with two render layers (one layer in focus and the other blurred) in order to blur all background objects. The in focus objects are on layers 1 thru 14 and the blurred objects are all in layer 15. One of the blurred objects in layer 15 is a simple plane with 4 verts which I am using as water in an outdoor scene. There are only 4 verts because I want perfectly flat water. I think this plane object is somehow the problem. When it is in blur layer 15 and layer 15 is activated and compositing is on, the render crashes. When I move the water plane to an in focus layer and the blur layer 15 is still activated and compositing on, the render also crashes. But when I move the water plane to an in focus layer and the blur layer 15 is deactivated and compositing is still on, the render is successful. For this scene, the water panel doesn’t really need to look blurred, so I am finally able to get the whole scene rendered. All the other objects in the 2 renders in question are in focus, so moving the water object to an in focus layer then deactivating blur layer 15 isn’t a problem.
Actually, I’m not sure if a perfectly flat panel where you can’t see the edges can even look blurred.
Now that I got this far, the next step will be to render the same scene at its final size which is going to be 6000x9000 pixels at 300ppi (20"x30"). Each of the 25 renders will be 6000x380 pixels which my computer is able to handle. The problem I ran into today doesn’t seem to be not enough power, but definitely something weird which I never saw before.
well, exr is an image format, specifically, it’s the format used by blender to save render buffers.
not sure if it’s in 2.5 yet (i will check), but in 2.49, there is an option to free the ram before compositing…
i don’t know if i really understand, but it sounds like blurring the water plane is causing blender to run out of ram. which means it will crash.
I’m not sure if this would have solved the problem but sub-dividing the plane a number of times probably would have made this problem go away.
There are a few issues, I believe anyway, with the way 2.49’s ray tracing worked, it was quite bad at handling very large flat surfaces with few vertices.
The exact same things happen when I use r26310 and r26316. However, these 2 higher revisions do not render the Musgrave Procedural Texture properly which is part of the material for the main object in the scene. It looks nothing like what it should and that’s why I’m staying with r24941 for now.
I tried subdividing the water plane at several different levels including extremely high, but that didn’t stop the crashes.
The water plane always renders OK in 23 of the 25 camera renders when in blur layer 15 and compositing is activated, but the 2 camera renders in question always crash. The 2 cameras always render OK when the water plane is moved to an in focus layer and rendering of blur layer 15 is deactivated. It doesn’t make sense. Why would 23 cameras render and composite, but the other 2 always crash? Maybe I will think of the answer after I get a few hours sleep tonight.
I just tried rendering at the higher resolution of 6000x380 and had no crash with any camera as long as I made compensation for the 2 problem cameras.
I downloaded 2.5AO r26600 today and here are the results.
-23 cameras render and composite.
-2 cameras still have the same problem. I must move the water plane from blur layer 15 to an in focus layer then deactivate blur layer 15. “Compositing” can either be ON or OFF, I get a blur effect in both cases (very strange, but that is what happens). I can tell it is blurred because the water color changes a little and gets a slight gradient.
-I tried a render after DELETING the water plane from the scene and leaving blur layer 15 activated and Compositing turned ON. Blender crashed. This makes me think the water plane isn’t causing the crashes, having the blur layer activated when rendering with the 2 cameras in question is the real problem.
-6000x380 pixels renders OK and can probably go higher in size.
-Musgrave Procedural Texture renders correct.
-Camera name is now readable (this is very good news).
Conclusion: I will keep on using r26600 until something better comes along.