[Bf-cycles] Render to memory buffer

[Guillaume Chéreau]

OK after some more tests it seems to me that the easiest would be to
create my own CPUDevice subclass and overload the draw_pixels method
to render into my own texture, then somehow set this as the session
device.
Does that make sense, or am I going to run into some subtle bugs with
this approach?

Regards,
- Gui

On Sun, Mar 18, 2018 at 2:31 AM, Lukas Stockner
<lukas.stockner at freenet.de> wrote:
> Answers inline.
>
> On 17.03.2018 18:10, Guillaume Chéreau wrote:
>>
>> On Sat, Mar 17, 2018 at 11:01 PM, Lukas Stockner
>> <lukas.stockner at freenet.de> wrote:
>>>
>>> - Are you fine with getting a raw float buffer?
>>
>> Yes that's fine, I can easily do the conversion to RGB.
>
> Okay, that makes things easier because you can just process the
> RenderBuffers directly and don't have to mess around with the film_convert
> kernels.
>>>
>>> - Are you using interactive rendering?
>>
>> Yes, I am looking for the same kind of rendering as in Blender, where
>> we start we a low res version and progressively improve it, if the
>> user changes the scene of the camera position, the rendering is reset.
>> It works more or less out of the box with the session->draw method,
>> but it is using OpenGL to do the rendering directly on screen. What -I
>> think- I want is to get the raw data and add put it into a dynamic
>> texture that I can integrate into goxel rendering.
>>
>>> - Do you want to support multiple devices?
>>
>> Not sure what that means.  I only want to render on screen, and also
>> into a file for export.
>
> I was referring to the MultiDevice functionality, which is currently used
> for rendering on multiple GPUs at once (and might in the future be used for
> network rendering). The problem with that is that each device has its own
> memory space, so you can't just write all tiles into a single buffer - you'd
> have to allocate per-tile buffers, copy them back to the host and then
> combine them there (which is what Blender does when doing a non-interactve
> render).
>
> Technically it is possible to allocate a single large buffer (on every
> device), have them write into it and then copy the right parts from the
> right devices to assemble it directly without moving stuff around, but since
> you can only copy back linear memory regions you'd have to modify tiling to
> split the image into horizontal slices (one slice per device). In fact, that
> is what Cycles currently does for viewport previews since OpenGL drawing
> also works better that way.
>>>
>>> The easiest approaches I can think of right now are either using a shared
>>> RenderBuffer for all tiles (already sort of implemented in session.cpp)
>>> or
>>> just copying the pixels from their buffers into your shared buffer
>>> similar
>>> to how Cycles for Blender does it in
>>> BlenderSession::do_write_update_render_result.
>>
>> OK thanks for the tips, I will have a look at that.
>> - Gui
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-cycles
>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles



-- 
Guillaume
guillaume.chereau at gmail.com
+886 970422910