I’ve recently updated our network/distributed rendering addon to support Blender 3.1 and noticed that in cases where one computer finishes its tile ahead of another, the call to RenderEngine.update_result no longer causes the finished tile to be drawn in the user interface.
I also note that there have been changes to this RenderEngine class of the Blender Python API since 3.0.1 that include a new method, RenderEngine.render_frame_finish, the docs, however, don’t mention what this method does and I a curious if I am supposed to use it in some way to make render results that are finished drawn to the user interface, or if it has some other purpose?
I can see it is being used in the cycles addon, but exactly what it is supposed to be used for still eludes me.
I really hope someone (@brecht ) might be able to explain what we must now do to cause a completed render result to be drawn to the UI, here’s the current code I am using for reference
#load a finished tile from the image file
result.load_from_file(tile_file_name)
#update the pixels in the image editor so the tile is now visible
self.update_result(result)
self.end_result(result, do_merge_results=False)
I would be ever so grateful for being educated on the right way to update pixels to the UI.
I’ve never used ‘update_result’ to load a partial result from a file on disk, so I’m not sure if using ‘update_result’ after ‘load_from_file’ is the right way to go. Has this code worked for you before the API changes? On the other hand I am also curious to see how ‘render_frame_finish’ can be used from the Python side… @brech ??
Hi this has always worked, from about 2.79 through to Blender 3.0 before the cycles X merge. We only noticed this behaviour now. The docs for RenderEngine.update_result state the following;
Signal that pixels have been updated and can be redrawn in the user interface
This hasn’t changed either, so I’m curious to know what has changed to stop the pixels being drawn from the loaded tile.
Ok. I only use ‘update_result’ when I launch the render ‘into Blender’, to update each tile. This code is still working properly in my addons. But for ‘render to file’, I use: begin_result, load_from_file, and end_result when the render is finished, to show the render in the image editor.
Cheers…
Lol! maybe? though it could just be that @brecht and the team are really busy They’ve got their hands full with a fairly new code base that is sparking a lot of bugs, or at least that is what I can see (I’m subscribed to the cycles project on developer.blender.org, seeing a daily digest of all the issues) is that there are quite a few bugs being worked on.
This probably isn’t a high priority, not yet anyway.
Also, can you explain more about how you use the RenderEngine class? Your name here POVmaniac hints that maybe you are involved with the POV engine? Am I wrong/right/neither?!!
I was just making a joke For sure, answer to this thread is not a priority.
And no, I am not involved in the PovRay project, although my nick refers to this, I have a own project, forked from another old engine.
render_frame_finish says this in the docs: Perform finishing operations after all view layers in a frame were rendered
Cycles uses this to load and denoise render buffers from its disk cache, and free some resources, after all view layers in a frame have finished rendering.
Super cool stuff @brecht, let me know if I can help, i can at the very least build a test branch and test since I know I can reproduce the problem easily enough. Also happy to do a code review if that makes sense for me to help in that way.
Ahh, so this is purely for cycles then? Or can other engines take advantage of it? Also is there a way to learn more about disk caching other than reading the code? Be great to see a block diagram of cycles if there is one, really helps to understand the system better.
I seems that I have issues also with ‘render region’ when is ‘cropped’ in the midle of the render window… the tile is not ‘live updated’. When the render region start in 0.0, work OK, as always. So meant that ‘update_result’ is working properly in the first case…