In my application I have a simple Blender scene consisting of:
- 4 cameras (all parented to a single object)
- some lights
- a couple of meshes.
As a rendering engine I use EEVEE and custom materials.
The user of my application needs to move the cameras, change the lights power and record the list of travelled positions while looking at a sufficiently photorealistic real-time rendering of the scene as seen from the 4 cameras.
I created an addon for this, and it kind of works but the Blender interface is too cumbersome to be given to non-expert users.
Therefore I decided to move all the user iteraction to a more intuitive external UI application (written in Python) that communicates to a Blender instance running in background without UI. The communication is already set-up, the only doubt is how to render the 4 viewports in real-time and send the renders to my application.
In other words: if in Blender I move a camera or change a light's power the rendered viewport is updated in real-time. I want to achieve the same feeling, giving some commands from my Python application to the background renderer and receiving back the rendered images within tolerable delay.
My solution so far:
For the communication infrastructure I use GRPC, so no particular delay/overhead should come from this.
At the moment, whenever the user performs any action in the UI an update message is sent to Blender, that triggers a render() command in Blender (actually, 4 render(), one for each camera present in the scene) thus saving the 4 renders in a folder. Once rendering is completed, Blender sends a finished command to the external application that picks up the rendered image files and displays them in the UI
The proposed architecture works but is too slow to be usable. Even lowering down the resolution of the renderings it takes 3-4 seconds to complete the renderings, so for every update the user has to wait that much time to see the updated rendering, therefore killing the real-time requirement.