Page MenuHome

Freestyle - bad images in animation + long time render
Open, NormalPublic

Description

System Information
ubuntu 14.04 - GTX 860M - i7

Blender Version
2.73a

Short description of error
Render an animation of freestyle strokes. Some frames are KO.
Some frames take long time to render (when most are render in 5-7s, some take 24s). Re-render long frame take normal time.

Exact steps for others to reproduce the error
Open blend file & render

Please find in attachment :

  • blend file
  • log of render time
  • test1_0200.png that is wrong
  • test1_0199.png that is OK.

Note that approximately 10 frames are KO in 200 frames in total
Complete render files (200) can be retrieved here : test_freestyle.zip

Don't hesitate to contact me for more information, hope you will find something, because this is not really predictable :-/

Details

Type
Bug

Event Timeline

Julien DUROURE (julien) updated the task description. (Show Details)
Julien DUROURE (julien) raised the priority of this task from to Needs Triage by Developer.
Julien DUROURE (julien) set Type to Bug.
Bastien Montagne (mont29) triaged this task as Normal priority.Feb 6 2015, 11:01 AM

On Windows the provided .blend file renders straight from the first to the last frame without any appreciable performance glitches and broken visual results. Tested versions include the current HEAD of the Git master branch built with MSVC and MinGW64, and official 2.73 and 2.72b binaries. The reported issue is likely specific to Linux?

I just tried it on a window 8 64 bits with Blender 2.73a 64 bits: All frames rendered without any problem.
The same with mageia 4 64 bits.
Not tested on ubuntu.

Hello,

Unfortunally, I have same issue on Windows 8 ( same computer, used with Dual Boot ) :-/
Some specifications :

  • .blend file is stored on USB drive
  • render path is on SSD

I have to test with different configuration (.blend file on SSD or HD / render path on HD ). Will post results here

Thanks for your investigation :)

I tested again your file on mageia, with Blender 2.72 64 bits, the frames 183 and 190 have the same issues. And frames 170,183,190,193 took more than 20sec (others less than 13)
File was on SSD and images on HDD.
I will try again on Windows with the same disk configuration.

As scheduled, I re-tested it on W8.1.
File and images were on SSD.

And... A fail happened at frame 116.
And at frame 125, after 2 minutes, Blender crashed: it was using about 8Go of RAM...

I hope that can help you.

I also took another look at rendering performance in terms of memory consumption. Under 64-bit Windows 7, both the official 2.73 Win64 build and my own Win64 build of the Git master branch head (2.73.9) worked fine. Memory consumption by the program is at most 1.2 GB in both test cases.

(In the plots above, there are two components in the memory usage trend. In 2.73 the increasing component over time is likely related to Freestyle stroke rendering, which has been optimized in the development version used in the other test case.)

@Lapineige, could you try to see the memory consumption trend (e.g., using the Task Manager's performance monitor) and check if the used memory is increasing over time? I suspect a memory leak, but I have no clue to whereabouts so far. And what Blender version did you use for the test on Windows 8.1?

I used 2.73a.
I didn't have time to re-render all the animation, but on the first memory usage seam to increase slightly (1,1Go,1,2Go,1,4Go...).
On my last test the task manager was saying Blender 8Go, but 14,9Go were used (I have 16Go), while only firefox were open. No other software used more than some Mo of memory... Maybe the memory leak is there.

Do you know a tool that can monitor memory usage and write it into a log file ? (because I can't wait 15 minutes seeing the memory usage ^^)

Hmm, sounds like a memory leak somewhere in Freestyle that is likely to depend on run-time environments...

As to memory usage monitoring under Windows, I have used my own Python script:

. You need Python 2.7 and the pywin32 package to run the script. Start Blender first and then run the script as follows:

C:\Python27\python blender_memory_usage.py > mem.txt

Logging will end when Blender terminates. You also need a plotting program such as Matlab, GNU Octave and gnuplot to visualize the log data. I have used gnuplot with a script like below:

set terminal png size 800,600
set output 'mem.png'
set xlabel 'Time [sec]'
set ylabel 'Memory [MB]'
plot 'mem.txt' using ($3/1024/1024) with lines title '2.73'

Hope these tips help you.

Hi Tamito,
Thanks for your script. I will test it on Windows, probably before end of the week.

Thanks :)

Thanks, I will try that.
I have tried to re-render again on W8.1 with same version, and this time it crashed at frame 54, without any issue on the rendered frames.
I saw 2 strange memory peaks:
At frame ~40:
http://i.gyazo.com/df0ad40a1202710d79679481736101e2.gif
(sorry i don't know how to use images)
Max: 5,1Go

and just after the crash:
http://i.gyazo.com/d79566223fe79054e2be7585cc1f836f.gif
Max: 4,2Go

Hello,

I currenlty have a problem to run win32 on my computer.
Will try to find a way to get it work, or find another computer to test.

Lapineige added a comment.EditedMar 14 2015, 2:55 PM

I didn't have test your script, but I made a new test: again Blender used more and more memory, up to 15,9Go. But it didn't crash this time: The memory usage level made some kind of bearing (while in stroke rendering), but it didn't used any CPU power. And after this bearing, the SSD is completly used.
Memory increase while rendering:
http://i.gyazo.com/6605456bedd8f40b7133caf6d1e12fd0.gif
http://i.gyazo.com/1371d4ce91716ef30e21278e32047a2b.gif
Just before the bearing:
http://i.gyazo.com/d201f40923242c1eadd3cf91ca03cf58.gif
And just after:
http://i.gyazo.com/7e2b42143bf0efa67d62a5258541c5b7.gif
And Blender was blocked with a big disk usage:
http://i.gyazo.com/16bd4e1c9ce7183a5d6f1ac03acc2ba8.gif
After 3 minutes I stopped it.

I found that the left rope is always blank, and the right one as a few "rings" blank (not the same, but quite in the same location).
Also it seams that the more the memory is "used", the more the render fails (more blank, less rope).

I hope that will help you :)

I managed to reproduce the reported problem on a Linux box. Will further investigate the issue.

Not sure about that, but seems to be linked to driver on sampling, when value is close to 0