I’ve tried just about everything I can now and something in my scene is causing Blender to crash every single time I attempt to bake the fluid in. I’ve tried various things I’ve found on this forum and others, yet nothing seems to even make the smallest difference. I’ve spent the whole day trying just about every single thing that I could think of to correct it, but despite the fact that I’m only using little over gig of ram the scene is impossible to complete. If anyone has the time, could you maybe check out my file and see what I’m doing to cause this? I mean it works for others so there has to be something I’m doing wrong.
As a complete noob to Blender I should also mention, it only appears to be using 12% of my processor during baking too, typical behaviour for Blender or should it be using much more of that power?
What version of blender are you running? From the filename I could infer Blender 2.5 but I don’t like to assume.
I loaded your blend and began baking, only to experience a crash as you reported. Running from console I found that a script was not loading, but it didn’t crash. The script was written by a newer blender binary (270.5) than mine (270). It presented a button to “Reload trusted”, which I took the risk to hit. Things started working.
I had to increase the End time in the fluid simulation as it was stopping far too early; I increased it to 10 seconds. Right now it’s baking and the physics looks good so far.
Based on this experience, if you are using an older Blender version, I think you just need to upgrade.
As for processor usage, it was only using 12% of mine with the settings you provided. I increased the number of simulation threads to 8 and it’s now using 38%.
Well, I have probably opened the file at some point with 2.5 to test, but it was primarily designed on 2.70. Also switched over to 2.70.5 to see if I could get any further relying on the CUDA cores, but no luck either. Thanks for taking the dive on the reload trusted, I only just read up on what that could actually entail. I managed to swap out the time settings for speed to match the gravity better instead, but unfortunately it still crashes
I decided to test it out on my laptop as well just in case and it crashed on that also. I really can’t figure out why, but I can’t seem to get any reliable result, the furthest it ever goes is frame 30 before either crashing or just giving up on baking. I guess I could probably rebuild from scratch again, but I just can’t figure what it is on both my computers that’s preventing it from working. To clarify my main PC has an i7 2600k, GTX580 and 8Gb of ram so I figured it’s more than enough headroom for this relatively simple simulation.
Edit: Don’t know if this is of any use but the errors windows reports stem from 3 files in the temp folder (Win7) here’s the file names.
If it works for some one when reload trusted is clicked very likely you have unchecked ‘auto-run python scripts’ in your preferences. Find it, check it and try again. You may also have (don’t know how) designated an unsafe directory for python scripts and your file is in that directory.
Ahh ok, Well I have the autorun enabled after a bit of googling last night and even then, still crashing. I’m guessing you’re probably right about an unsafe directory, perhaps since I installed to the root of my D drive? I don’t know if that could maybe have an effect since it’s relying on writing temporarily to an SSD (C://) whereas the D:// is just a HDD. I can’t really think of much else as I would have no doubt installed to D:// out of habit.
Like you say, it working for others indicates it’s something wrong on my end. I have a good amount of spare time again today so I think I’m going to start by backing up the files from the project, delete everything Blender/Python on my computer and reinstall to C, which unfortunately is lacking on space. Reload the files to test and if needs be build from scratch again. I figured the debug console may help, but it didn’t shown anything at all when baking or crashing either, I’m not sure if that’s because there’s no code in the files or what, but I may also need to learn a bit more about debugging I guess before I can make progress.
Really appreciate the help here guys, I know it’s likely something I’ve done to myself having worked with DAW’s in the past, but as always with complex software to anyone who’s extremely new to it, tracking that issue can be almost impossible. You’ve certainly helped me to trim the fat from things I may have done wrong so hopefully I’m closing in on the issue.
It is all those shards. You actually assigned a fluid sim collision modifier to every single shard. We know that cell fracture can produce 0 face shards so that might be what is going on here. You are telling the fluid sim to use invalid mesh objects for collision. I think you have found a bug and should report it. I have reported the 0 face shard bug a while ago.
To solve this simply select all the shards, make sure one is the active object, and change the fluid sim type from Obstacle to None. Then use CTRL-L to link that modifier settings to all other shards in the selection. At this point the fluid sim bakes without crashing. i.e. no collision object except the bullet. What you can do now, however is choose some of the bigger pieces and change those fluid types back to collision.
Thanks man! That was exactly the root of the problem! After a bit of messing around I’ve found a better balance, though I decided to redo the fracturing to reduce the strain on the computer too. For some reason Blender seems to choke a fair bit earlier that the tutorial I followed indicated when using shards as obstacles. I seem to be able to get it to bake properly now, just the Obstacle limit seems to be little over 10. Thanks though, I feel like I’ve just been banging my head against the wall trying to figure why it was crashing and was starting to think maybe this just isn’t for me. Now I can push on with getting my first project finished.
I’m going to toy around a bit more to see if the bug is coming from a 0 face shards issue from cell fracture, but currently it seems just related to the amount of objects with slip and has a very low ceiling compared to other simulations I’ve seen created on it as it even occurs when using a reasonably basic fracture with all of the large shards and no small shards.
