Blender crashes when rendering high resolution fluids... anyone know why?

[andrewprice]

Hi all!
Blender crashes every couple of frames when trying to render this animation:

^ Frame 127 out of 250.

At first it was able to render nearly 50 frames without crashing, but as more and more water sloshed around on screen, blender started crashing more frequently.

I’m rendering this on:
Windows XP 32-bit
2.66Ghz Intel Pentium 4 Core 2 Duo
2 Gb RAM
GeForce 6600GTS

Each frame takes approximately 4 minutes to render.

Does anyone know the reasoning behind this?

I read somewhere (but it could be wrong) that the fluid system requires a lot of memory, and when it runs out of RAM, it has to swap to hdd memory. However Windows has difficulty doing this and crashes. Is that about right?

I’m considering installing Ubuntu over the weekend but I want to make sure it’s not going to have the same problem.

Thanks in advance!

[mattebb]

Try running blender from the console, so you can see any messages it leaves after it crashes. If it leaves messages like ‘calloc returns nill’ or ‘malloc returns nill’ it’s a pretty good indication that it’s running out of memory. If you do see messages like that, post them and we can try and figure out what it is.

PS. that frame looks sweet!

[musk]

I’d say this is definetly a memory issue. Try starting Blender with -debug and see if the output in the console reveals anything indicating a memory issue.

EDITED: Broken beat me to it

[andrewprice]

Hey thanks for the reply guys.

This is the readout from the debugger:

fsme items: 11, len: 0.000 MB
RecentFile items: 10, len: 0.000 MB
Data from PA items: 1, len: 0.000 MB
pysubmenu items: 8, len: 0.000 MB
gqueue_new items: 8, len: 0.000 MB
RenderWin items: 1, len: 0.000 MB
lamp jitter tab items: 1, len: 0.000 MB
soundlistener items: 1, len: 0.000 MB
Data from TXT items: 4, len: 0.000 MB
DAG root items: 2, len: 0.000 MB
Data from WO items: 1, len: 0.000 MB
GHash items: 1, len: 0.000 MB
PackedFile items: 1, len: 0.000 MB
memarena items: 1, len: 0.000 MB
PointCache items: 1, len: 0.000 MB
temp_font items: 1, len: 0.000 MB
Malloc returns nill: len=60790248 in edgesort, total 1164077512

And I guess that last line explains it all… :o

Whilst we’re on the topic, I have a few more questions if anyone cares to answers:

1. Will installing Linux instead of Windows help this issue at all?
2. If I were to build a new PC, what is the maximum amount of RAM that Blender could use? Is 4 Gig the cutoff?
3. How does using render management software (like Dr Queue) effect this? Does it pile all the RAM together and use it all at once?

Thanks for the help guys!
My goal is for a super realistic looking flood!

[mattebb]

@redbyte

1. Will installing Linux instead of Windows help this issue at all?
2. If I were to build a new PC, what is the maximum amount of RAM that Blender could use? Is 4 Gig the cutoff?
3. How does using render management software (like Dr Queue) effect this? Does it pile all the RAM together and use it all at once?

Unfortunately it seems you’re running out of memory for the geometry, which is harder to work around than if it were textures or something.

1. 64bit Linux and Blender will most definitely help, even 32bit Linux may have some advantages but not so drastic.
2. It depends on the operating system. If you’re using a 64bit OS and Blender version you’ll be able to use as much RAM as you have. Currently the only OS with a released 64bit version is Linux (well, maybe some of the other unixes too?). 64bit Windows should now also be supported in Blender svn, but you’ll need to get an unofficial build for that, perhaps from graphicall.org.
3. Unless you’re thinking of something that I’m not, DrQueue is a render farm manager - i.e. distributing an animation over multiple machines by sending them different frames. It won’t help crashing on a single frame at all.

[andrewprice]

Well I’ll definitely be using a 64-bit Linux OS then.
Think I’ll go out and drop a few thousand on a dedicated Blender machine.

@broken

3. Unless you’re thinking of something that I’m not, DrQueue is a render farm manager - i.e. distributing an animation over multiple machines by sending them different frames. It won’t help crashing on a single frame at all.

Ohhh so that’s what DrQueue does. I’ve never used it before, but I assumed it used all computer’s processing power combined to render each frame together. Guess there’s no real point in using it then. :no:

Thanks for the help broken!

[ChojinDSL]

Ok, here’s the deal.

With 32bit Linux blender can access 4gb of Ram.

With 64bit Linux blender can access as much RAM as your Motherboard allows.So that could be 16gb or 32gb. The limit for 64bit in terms of RAM is quite high. I think more than a terabyte or so. Not sure.

Anyways. If you are building a PC just as a render server. You might wanna consider doing a Gentoo Linux 64bit install. You can keep it nice and lean and your entire system will be compiled specifically for your CPU.

If your not that familiar with linux go with the 64bit version of Ubuntu.
Both distros have a VERY supportive community. Whereby in the gentoo forums you will usually find a higher level of expertise than in the ubuntu forums.

Oh yeah, needless to say. Go with a Intel Quad Core CPU!
The AMD quad cores have had some issues with bugs in the past, but in terms of performance and efficiency the Intel Quad Cores are better. The cost is rather similar as well. Or at least it was last time I looked.