Page MenuHome

Freestyle gives no visual output when the Save Buffers option is enabled
Closed, ResolvedPublic

Description

System Information
Windows 7 64-bit, NVIDiA Quadro 1000M

Blender Version
Broken: rBd5f1b9c2223333e03f2e4994171ad9df8c1c4f21 and later
Worked: 2.74 release, and up to rB74df307ca43df14b759fd9eb6a049a6c5d90dcda

Short description of error
Freestyle line rendering gives no output lines when the Save Buffers option enabled.

Exact steps for others to reproduce the error

  1. Start Blender with the factory settings.
  2. Enable Freestyle as well as the Save Buffers option, both in the Render properties window.
  3. Press F12 to render a still image.
  4. Observe that the default cube will be rendered without Freestyle lines.

The documented combination of Freestyle and Save Buffers options initially resulted in a fatal crash, which was partly addressed in rB8c1b805f87209ae6282d77b213ed2527f2d7c207. Still the Save Buffers option does not work as expected with Freestyle.

Acknowledgement: tksg8086 on Twitter for initial problem report.

Event Timeline

Tamito Kajiyama (kjym3) claimed this task.
Tamito Kajiyama (kjym3) raised the priority of this task from to 90.
Tamito Kajiyama (kjym3) updated the task description. (Show Details)
Tamito Kajiyama (kjym3) edited a custom field.

@Dalai Felinto (dfelinto), I would appreciate it if you could take a look at the reported issue and help me address it.

Bastien Montagne (mont29) lowered the priority of this task from 90 to High.May 11 2015, 9:32 AM

When Full Sample is enabled, there is no problem.
Freestyle lines are saved as a separate .exr file in temp directory.

But it seems that combinaison of freestyle lines buffer and regular render buffer is not done when Full Sample option is not enabled.

I don't know if it's related, but simply turning Views on and rendering with Freestyle gives me a crash:

#1  0x00007fff8ed1235c in pthread_kill ()
#2  0x00007fff8d3f4b1a in abort ()
#3  0x00007fff8e4a407f in free ()
#4  0x00000001013893a2 in MEM_lockfree_freeN (vmemh=0x1177078c8) at /Users/dfelinto/blender/git/blender/intern/guardedalloc/intern/mallocn_lockfree_impl.c:169
#5  0x00000001007232d4 in RE_FreeRender (re=0x10a920808) at /Users/dfelinto/blender/git/blender/source/blender/render/intern/source/pipeline.c:523
#6  0x0000000100725470 in free_all_freestyle_renders () at /Users/dfelinto/blender/git/blender/source/blender/render/intern/source/pipeline.c:2145
#7  0x000000010072ce5b in do_render_composite_fields_blur_3d (re=0x1082a9808) at /Users/dfelinto/blender/git/blender/source/blender/render/intern/source/pipeline.c:2472
#8  0x000000010072792d in do_render_all_options (re=0x1082a9808) at /Users/dfelinto/blender/git/blender/source/blender/render/intern/source/pipeline.c:2647
#9  0x000000010072729b in RE_BlenderFrame (re=0x1082a9808, bmain=0x10a956608, scene=0x10a962608, srl=0x0, camera_override=0x0, lay_override=0, frame=1, write_still=false) at /Users/dfelinto/blender/git/blender/source/blender/render/intern/source/pipeline.c:3044
#10 0x00000001005e9060 in render_startjob (rjv=0x115483508, stop=0x11540b7dc, do_update=0x11540b7da, progress=0x11540b7e0) at /Users/dfelinto/blender/git/blender/source/blender/editors/render/render_internal.c:600
#11 0x0000000100023a00 in do_job_thread (job_v=0x11540b768) at /Users/dfelinto/blender/git/blender/source/blender/windowmanager/intern/wm_jobs.c:328
#12 0x0000000101336c51 in tslot_thread_start (tslot_p=0x1154093f8) at /Users/dfelinto/blender/git/blender/source/blender/blenlib/intern/threads.c:252
#13 0x00007fff8ed11899 in _pthread_body ()
#14 0x00007fff8ed1172a in _pthread_start ()
#15 0x00007fff8ed15fc9 in thread_start ()

I could reproduce the error on my side (Windows 7 64-bit, VS 2013).

>	blender-app.exe!RE_engine_free(RenderEngine * engine) Line 154	C
 	blender-app.exe!RE_FreeRender(Render * re) Line 507	C
 	blender-app.exe!free_all_freestyle_renders() Line 2146	C
 	blender-app.exe!do_render_composite_fields_blur_3d(Render * re) Line 2476	C
 	blender-app.exe!do_render_all_options(Render * re) Line 2649	C
 	blender-app.exe!RE_BlenderFrame(Render * re, Main * bmain, Scene * scene, SceneRenderLayer * srl, Object * camera_override, unsigned int lay_override, int frame, const bool write_still) Line 3046	C
 	blender-app.exe!render_startjob(void * rjv, short * stop, short * do_update, float * progress) Line 602	C
 	blender-app.exe!do_job_thread(void * job_v) Line 329	C
 	blender-app.exe!tslot_thread_start(void * tslot_p) Line 253	C
 	pthreadVC2.dll!000007feeff4627b()	Unknown
 	pthreadVC2.dll!000007feeff48eb7()	Unknown
 	pthreadVC2.dll!000007feeff49102()	Unknown
 	[External Code]

No crash happens if one view is rendered, although Freestyle lines appear in a wrong place (all lines are shifted a bit in the positive X direction). Will look into it as well. We might have to file a separate issue for the documented problems.

The build version of blender-2.74-dc95ca9-win32 crashed.
The build version of blender-2.74-9e2e85a-win32 does not crash.

For the records, this (the reported bug, not the crashes) happens only with Blender Internal, which makes me suspect it is related to T44682 (which also only affects Blender Internal)

line of frestyle is drawn normally in _FRS1_Scene_RenderLayer_exr output by a temporary folder.

The problem is dest = RE_RenderLayerGetPass(rl, SCE_PASS_COMBINED, re->viewname); being NULL (in FRS_composite_result()).

The issue is related to the changes multiview introduced into pipeline.c.

Basically at the moment we only read back the rendered data when we run main_render_result_end()
But the call to freestyle is happening before that.

We should do as we do for multisampling (see: composite_freestyle_renders()). Basically, render the freestyle as we do now (in do_render_3d()), but we run FRS_composite_result() only after everything is rendered.

@Tamito Kajiyama (kjym3) how does that sound?

This is still marked as "High". Any news here? ;)

Committed modified workaround for the issue. Think we can stop considering the report a stopper for 2.75. But it needs a real solution still!

Thomas Dinges (dingto) lowered the priority of this task from High to Normal.Jun 14 2015, 4:05 PM