Eevee Preview Render from Python

Question

As part of my Bachelor thesis I'm looking to render a live preview of the model on the RealFiction Dreamoc HD3, a holographic display with three viewing directions.

Using bpy.ops.render.render() is too high quality, resulting in the three renders of the default scene (a plain cube) taking ~0.5 seconds, far from the desired 30 fps. Even rendering at decreased resolution (1280x720) and one side per frame leaves my addon at ~0.12s, still far above 0.0333s.

It would seem the only option is to render at "editing" quality, i.e. the quality the user can see on the main display, but I haven't been able to find anything on this in the documentation. Is this even possible?

Answer 1

Not direct answer, but maybe helpful if you choose the way of the viewport. The viewport is mainly faster because the GPU pushes the image directly to the screen instead of copying it back to the cpu for colomanagement and other calculations. So using the viewport, maybe directly pipelining it to whatever other output you seek might be one of the fastest solutions possible.

More detail below, basically a question and answer to and from a blender developer: https://youtu.be/YqOs-VwehuM?t=1175

Rough transcript:

Question: "...but along those lines I've noticed that when I try to render out the EEVEE viewport, it's significantly slower, even if I'm just rendering out as if in the OpenGL viewport in 2.79 when I'm just trying to render out hte viewport settings equivalently I get significantly slower render times and if I'm trying to render out a significant portion of a significant frame count I can preview it at 60 fps, but when I render it out it's something like 5 fps ..."

Answer: "...basically when you do it in the viewport it's rendered by the GPU and it's displayed directly on the GPU so that's fast and if you are doing a play back blast (?) in the viewport it only calculates a single sample. So when you render to an image a lot other stuff will happen. It renders 64 samples, but that's not the main case that happens. What happens next is that the GPU in image is copied back to the CPU and on modern GPUs that's a really slow process, you can only do it 20 times per second. That's the main burden of that. Why do we copy it back to the CPU? That's for the color-management that's for the sequencer, that's for the compositor."