Systematic crash on the same frame number whatever rendering options chosen
Closed, ArchivedPublic

Description

Hello,

I made this little scene using physic system with the 2.64 (Windows x64) version, and I had a systematic crash on the rendering of the 28th frame whatever rendering options chosen.
Now, I work with the new 2.65 (Windows x64) version, and I have the same systematic crash during the rendering, however I recalculated the bake fluid simulation with a better accuracy (300 instead of 200) now that I have an Intel i7 6 cores.

Just for your information, my PC is totally new, I made it myself (it's a part of my job) at the beginning of this week. It's a really "fresh" Windows 7 Pro x64 installation, with the lastest official, and stable, graphic card driver of my Nvidia GTX660Ti. You could see all my configuration in the system-info.txt

I'm not a superuser of Blender, but as the crash continues despite my new machine and the new Blender version, I think this is really a rendering bug.

Well, that's all for me, I can't give you more informations now.

Thanks in advance for your work and have a nice day
Bye

ton (Ton Roosendaal) added a comment.Via Old WorldDec 13 2012, 7:04 PM

Without fluid bake it renders incredible slow already - and a bake takes hours or more.
It's first important that you help us to reduce the problem, so it can be checked in a matter of a minute.

I've never done fluids really, Daniel Genrich might know more.
But you can probably just attach the frame 28 from the fluid cache here?

ton (Ton Roosendaal) added a comment.Via Old WorldDec 13 2012, 7:16 PM

BTW I made a cache with resolution 100, rendered OK.

genscher (Daniel Genrich) added a comment.Via Old WorldDec 13 2012, 7:17 PM

@ Lionel: Does it crash during simulation or during rendering?

shkyo30 (Lionel Alvergnas) added a comment.Via Old WorldDec 13 2012, 8:01 PM

It crash only during rendering, never during simulation. And if you need, I can send you the cache of the frame 28.

Another information, during other tests with this scene, I found another "crashing frame", the number 38 with exactly the same effects of the 28th: an immediatly Blender crash just after F12 touch!

genscher (Daniel Genrich) added a comment.Via Old WorldDec 13 2012, 8:11 PM

I just got to Frame 28 in your file and it renders fine here (WIn7 x64, latest blender svn, just pressinf F12 in your file). Are you using the official blender release version from blender.org?

shkyo30 (Lionel Alvergnas) added a comment.Via Old WorldDec 13 2012, 10:59 PM

Yes, I use the official version 2.65 Windows x64 directly downloaded from blender.org two days before. It's very strange, for me at the frame 28 or 38 when I press f12, blender directly crash!
Even if I change resolution, or antialiasing parameters, or anything else! Always a big crash...

And I had the same problem before with the 2.64a version (x64 too), I don't understand where is the problem. Tomorrow, to try to find some information useful for you, I'll try to speak to Blender users on a french forum to do other tests on .blend file

genscher (Daniel Genrich) added a comment.Via Old WorldDec 13 2012, 11:46 PM

As an intermediate help you could attach your simulaiton result of the 28th frame so I can test if your simulation result differs somehow.

shkyo30 (Lionel Alvergnas) added a comment.Via Old WorldDec 14 2012, 9:07 AM

I tried just now but I can't! I have an error message: "Missing Parameters" from the website, yet the file are under 5mb (4.4mb exactly in a zip file), maybe can I send you by mail?

shkyo30 (Lionel Alvergnas) added a comment.Via Old WorldDec 14 2012, 12:07 PM

I uploaded the files on my website, you can download them here: http://www.photospicsandco.com/divers/

ton (Ton Roosendaal) added a comment.Via Old WorldDec 14 2012, 2:30 PM

Lionel: thanks, crash is confirmed now!

Genscher: Sergey found out that the data in the cache file is corrupted with NaN vectors in it.
http://www.pasteall.org/38022

Such things can happen in sims... but easy to prevent?

genscher (Daniel Genrich) added a comment.Via Old WorldDec 14 2012, 2:50 PM

The better question for me is: Where do this NAN's come from since I have the very same setup. And internally I thought elbeem already checks for NAN's, mhm. Mysterious.

shkyo30 (Lionel Alvergnas) added a comment.Via Old WorldDec 14 2012, 2:52 PM

A cache file corrupted? But it's strange, because I had the same problem with another simulation (with 200 instead of 300 from accuracy) at the frame 66 or 68, I don't remember exactly...
In the same time, on two french forum, some guys used my scene and my cache files, downloaded from my website, and it's ok for them, no crash! Now, I trying with my notebook and with exactly the same scene&cache files, and I'll send you results quickly!

Have you a method to prevent this cache file corruption?? Because it's not a complex fluid simulation, just one drop that fall in a cube! We can see many examples of very very complex fluid simulation on the web made with Blender.

ton (Ton Roosendaal) added a comment.Via Old WorldDec 14 2012, 2:52 PM

Maybe the cache reader code can detect it? would make things work...

shkyo30 (Lionel Alvergnas) added a comment.Via Old WorldDec 14 2012, 3:09 PM

I don't know the cache reader code function, is it difficult to use?

Last news: I just tried with my Asus notebook (Windows 7 pro x64 too) and the 2.65 version. I used always the same files and... directly crash too!

shkyo30 (Lionel Alvergnas) added a comment.Via Old WorldSep 17 2013, 1:37 PM

Hi! Just to see, I just tried the same frame (28) of the same scene with the 2.68a (x64 version), and... directly crash! Very strange...

genscher (Daniel Genrich) added a comment.Via Old WorldOct 29 2013, 4:26 PM

Still can't reproduce with latest svn, sorry :(

Maybe someone else who can reproduce the bug can fix it?

Will de-assign me.

Hello,
I was curious to verify if this issue is still there in the latest versions of Blender 2.69.0 r60995, and 2.70a hash: f93bc76 both 64bit Zipped file option and installed into their own respective dedicated folders adding also the /autosave, /cache, /config, and /temp directories to enforce a controlled testing environment under Windows 7 Pro w/SP1 64bit.

Then I downloaded the initial sample file test_goutte5.blend, put into its own dedicated folder, opened in Blender, set the frames from 1 to 42 and baked the fluid simulation into its specific directory (//cache_fluid) at 200 resolution. Finally I started to render the animation for those 42 frames at half the HDTV 720p resolution and I didn't get any error or issue with the rendering or its resulting images.

I did the same opening that file in version 2.70a and rendered the animation again saving the resulting image files into a separate directory. No issues or problems again.

Is there anybody else facing this same problem? In the contrary, may I suggest the admins to close this bug ticket?

sergey (Sergey Sharybin) closed this task as "Archived".Via WebMay 19 2014, 5:25 PM
sergey (Sergey Sharybin) claimed this task.

Quite a while without reply from the original author. Nobody actually was able to reproduce the crash. So archiving for now. Will reopen if it's an issue for the author and he can reproduce it with new bakes made in fresh blender version.

Add Comment