[Bf-cycles] problems with function callbacks from Cycles standalone exporter

[Mohamed Sakr]

but I'm sure it doesn't crash from the function content, even if the
function is empty "just return; " , it crashes

On Tue, May 19, 2015 at 12:17 PM, Mohamed Sakr <3dsakr at gmail.com> wrote:

> Hi Sergey,
>
> it didn't solve the issue "although I guess it is a part of the crash, so
> there is another part that crashes it here too" , it crashes in both CPU
> and CUDA, when I tested with CUDA it throws this message:
> ILLEGAL_ADDRESS in cuCtxSynchronize()
>
> here is the code that I'm using for the function callback:
>
> void rContextHandler::r_C4D_write_tile(RenderTile& rtile)
> {
> BufferParams& params = rtile.buffers->params;
> int x = params.full_x - options.session->tile_manager.params.full_x;
> int y = params.full_y - options.session->tile_manager.params.full_y;
> int w = params.width;
> int h = params.height;
>
> RenderBuffers *buffers = rtile.buffers;
>
> /* copy data from device */
> if (!buffers->copy_from_device())
> return;
>
> float exposure = scene->film->exposure;
> std::vector<float> pixels(params.width*params.height * 4);
>
> if (buffers->get_pass_rect(PASS_COMBINED, exposure, rtile.sample, 4,
> &pixels[0]))
> write_c4d(&pixels[0], x, y, w, h);
>
> return;
> }
>
> On Tue, May 19, 2015 at 9:40 AM, Sergey Sharybin <sergey.vfx at gmail.com>
> wrote:
>
>> I can't reproduce issue with missing update/write callbacks call here,
>> this all works just fine here by the looks of it. Also not sure why would
>> commenting buffers deletion make things work to you. Either you're
>> referencing buffers in the callback or maybe it is related to the next
>> issue.
>>
>> Bet you've got default start resolution of 64 in the settings. This makes
>> it so frame first renders with lower resolution and then goes to a final
>> resolutions. This for sure causes number of tiles to be changed, which is
>> not supported by progressive refine in the background mode.
>>
>> Surely we can add some checks in the session constructor to verify the
>> settings, but for until then just manually control the settings on your
>> side.
>>
>> On Tue, May 19, 2015 at 3:21 AM, Mohamed Sakr <3dsakr at gmail.com> wrote:
>>
>>> Hi,
>>>
>>>     I'm creating a render engine based on Cycles, right now everything
>>> is fine except that the function callbacks "write_render_tile_cb,
>>> update_render_tile_cb" and variables "progressive, progressive_refine" are
>>> making a problem!!
>>>
>>> the problem is:
>>> case (1):
>>> options.session_params.progressive = true;
>>> options.session_params.progressive_refine = true;
>>> options.session_params.progressive_update_timeout = 0.1;
>>> options.session_params.background = true;
>>>
>>> no feedback is given "from both functions, so they are not called" , at
>>> the end of the render it saves the image on destructor.
>>>
>>> case (2):
>>> options.session_params.progressive = false;
>>> options.session_params.progressive_refine = false;
>>> options.session_params.progressive_update_timeout = 0.1;
>>> options.session_params.background = true;
>>>
>>> crash!! after first tile, shows 12/192 in tiles and crashes.
>>>
>>> case (3):
>>> options.session_params.progressive = false;
>>> options.session_params.progressive_refine = false;
>>> options.session_params.progressive_update_timeout = 0.1;
>>> options.session_params.background = true;
>>>
>>> and in session.cpp:
>>>
>>> void Session::release_tile(RenderTile& rtile)
>>> {
>>> thread_scoped_lock tile_lock(tile_mutex);
>>>
>>> if(write_render_tile_cb) {
>>> if(params.progressive_refine == false) {
>>> /* todo: optimize this by making it thread safe and removing lock */
>>> write_render_tile_cb(rtile);
>>>
>>> //delete rtile.buffers;  // I commented this line!!
>>> }
>>> }
>>>
>>> update_status_time();
>>> }
>>>
>>> with commenting delete rtile.buffers; , it doesn't crash, and updates
>>> fine!! "although with some problems in gamma in updating, but at the end
>>> the written image is gamma correct"
>>>
>>> I'm not sure where is the problem.
>>>
>>> cheers,
>>> Mohamed Sakr
>>>
>>> _______________________________________________
>>> Bf-cycles mailing list
>>> Bf-cycles at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>>
>>>
>>
>>
>> --
>> With best regards, Sergey Sharybin
>>
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20150519/8ceec411/attachment.htm