[Bf-cycles] progressive updates from a headless CUDA render

[Sergey Sharybin]

Hi,

Didn't have chance to check exact meaning in details to verify your change,
but i agree background/progressive/progressive_refine are confusing. There
is also headless flag..

Would propose moving towards easy-to-follow meaning here, merge progressive
and progressive_refine. Those are same thing, just one for the interactive
render and other is for final render. Background is probably cleanest is to
rename to interactive (so it doesn't conflict with Blender's background
meaning). headless i think is clear enough already.

This will cause some potential merge conflicts when integration guys will
update Cycles so because of that i don't want to do it "silently".

Would such a change help or will only cause extra pain for you guys?

On Wed, Mar 8, 2017 at 5:16 PM, Stefan Werner <stewreo at gmail.com> wrote:

> Hi,
>
> I’m integrating Cycles into a headless standalone application and am
> trying to get progressive updates from a CUDA render. As it looks like
> right now, I don’t think I can pull that off without modifying Cycles
> itself.
>
> (the following text is ignoring the OpenCL backend, that one I haven’t
> looked at yet)
>
> First, there are three flags to play with, and it doesn’t seem that all
> possible combinations are supported:
> SessionParams.background, SessionParams.progressive_refine and
> SessionParams.progressive. The name “background” was initially a bit
> confusing to me, but I found out that it’s intended to distinguish between
> a “fire and forget” render task and an interactive rendering session that
> keeps the session alive for updates (= viewport rendering in Blender).
>
> For a headless application, currently the background=false mode is not
> available with CUDA rendering. Attempting to use that combination without a
> valid current OpenGL context crashes the application on my Linux machine.
> Eventually, I’d like to be able to use background=false (interactive
> session) without OpenGL, and this could probably be of interest to other
> developers too (to integrate Cycles into applications using Vulkan, Metal
> or DirectX, for example).
>
> In the case of background=true and progressive=true, a combination which I
> believe Blender is not using, things look slightly better. It doesn’t
> crash, it works fine with CPU and returns black frames for CUDA. I have a
> simple change to get it to return frames with CUDA, but I’d like to get
> other opinions if it is valid:
>
> In session.cpp, line 567, replace
>
>         if(!params.background)
>                 need_tonemap = true;
>
> with
>         if(!params.background || params.progressive)
>                 need_tonemap = true;
>
> Does anyone have any thoughts? Am I misunderstanding the flags? Has anyone
> else who is plugging Cycles into a 3rd party application come across this
> or even solved the problem of progressive CUDA renders without OpenGL?
>
> Thanks,
> Stefan
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles
>



-- 
With best regards, Sergey Sharybin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20170309/9ab594c9/attachment.htm