I’m trying to render a scene at 4500x3000 pixels. I’m using about ten layers with 500000 vertices (in total). I’m rendering 16 parts to keep the load down (not exactly sure how to guess how many to use). During render Blender is using about 1GB of memory and about 1.5 GB of swap memory. At some point it always crashes.
(the system is an AMD 1.6 GHz, 2 GB ram, nvidia FX5200, Ubuntu 7.10)
Any tricks to avoid this?
I’m using nodes, so one thing I could do is render the layers seperately and combine them afterwards in Gimp. But I’d rather not as this will be more cumbersome.
So what do I do? And what extra information do you need?
Hi guys, thanks for your quick replies. I have made the number of parts larger and that helps a it bit further, but it still crashes. So I will submit it as soon as I have time. (Running late for a deadline due to the crashing).
Yes, I am using 2.45. So I’ll have to try an SVN. I had hoped that could be avoided, but I guess once I figure it out it won’t be too hard.
Hi Mike_S, sorry for the nooby questions but I was trying to follow these basic makefile tips
First of all, make sure
you have the full source tree available, either via CVS or as source download.
you have the libs dir (CVSROOT/lib/ or bf-blender/lib/ ) checkout as well
and I’m not clear on what I should do to make sure 1) and 2) are done. :o I don’t know a single thing about CVS, so I guess I should get the source tree available as source download. I’m assuming we’re talking about this tree here: https://svn.blender.org/svnroot/bf-blender/trunk/blender/source/
So on Ubuntu (7.10), am I supposed to include this address in synaptic as a repository? Or am I supposed to download it some other way?
O and just to have checked, there aren’t nicely prebuilt thingies lying around right? That’s not the idea here I think, but it can’t hurt to ask…
Until you can confirm its a defect in the code, it’s probably not a bug in blender, and I respectfully disagree about submitting it. What does your console say before the crash? When you start rendering, move your console window to the front. If it says malloc() returns nil, you are just running out of memory and there is nothing that Blender can do about that.
What you need to do is configure Blender so that it operates within your machines’ constraints. See the User Manual, Render Introduction page, for about 50 tips and ideas of things to do. Saving buffers comes to mind, as well as compositing
Right you are PapaSmurf, I’ll first try to narrow it down a bit. At the moment I’m making smaller images of just a few layers to keep the load down. I’ll assemble them in Gimp afterwards. I’ll try to fine tune my configuration before submitting anything. That’s also the reason I’m going to wait till I’m done with my deadline. I want some time to mess around with it and find the smallest bite that makes it choke and see if I’m not just messing things up myself.
I always composite as this saves rerender time, but now you mention it I mostly make sure to turn the “save buffers” button OFF, because I find that turning that on makes Blender crash more often somehow and on smaller and easier things, too. I really do need to mess around with this I guess. Other things I’ve noticed is that saving to openEXR doesn’t work and a few scripts don’t work either. I do remember using a few a while back, so I think at least some of them work, I’ll have to check to be sure. Sounds like a desaster now I list all this, but usually its pretty smooth running. I’ll start watching my console…
OK, now I have more time, I want to figure out what went wrong. Using 2.45 on Ubuntu 7.10 I find that using “save buffers” always crashes blender. I’m using square tiles, eg Xparts=1, Yparts=1, resolution 800x800 pixels with the default empty scene (the default cube and settings).
As I understand it those buffers are saved in the .exr format. So I made sure libopenexr2c2a was installed and libopenexr-dev too. Doesn’t help. Rendering to openexr with the lossless zip codec (“none” doesn’t work for some reason), I also find that blender always crashes if I try to save to an openEXR file. So at the moment that’s as far as I can limit the problem.
Also I find that many of the errors output by blender are more informative to those that would see the subroutine malloc() and immediately think “ISSUE WITH MEMORY ALLOCATION!!” In other words programmers and those with cursory programming knowledge. Easy to decipher error msgs would definetly help someone out who, say, has this same issue on thier first day with blender and has never so much as seen a source in any language.
I’m not too familiar with C’s error handling. My C code was never effecient to say the least. But I do know python like the back of my hand, and the ability to change this error msg so it says something more like “Error-you’ve run out of memory. For tips on how to avoid this issue visit …” or something like that is there, and it’s very simple to get it done, anyone with python experience could code that. That would definitely save everyone some confusion during, at least, thier first encounter’s with any bug in blender…or any program for that matter.
I’m not going to say I’m not at fault for having this same mindset. My error handling is often vague, but only because I know what that error msg of “Capt the delithium crystals are breaking up” means because I wrote the exception for it. However Joe over in wisconsin would never know what the hell that meant until he either read docs or asked around for others with similiar issues.
Just for the record the error msg isn’t one I’d use…it was ussed for example purposes. Mine are vague…but never that vague lol
@House: Please do so. However, most people don’t know to check the console, as with this thread. Or if they do and see the message, they don’t know to search the user manual. In spite of that, any little bit we can do to make it more friendly is a go in my book.