I know that Cycles is implemented as a Blender add-on and can be accessed - in theory - from the Python API by the “_cycles” or “cycles” modules. I wonder, if something similar exists for the workbench render engine? Can the engine also be accessed from within the Python API in a similar way one could do for the Cycles render engine?
Background:
I am asking this, because I have an ongoing project where a volumetric / lightfield display can be used to display final Blender renders and the Blender viewport. However, the latter is really slow due to some hackish workarounds. If I could access the workbench API from within python to subclass a bpy.types.RenderEngine for it, I think I could get way more efficient
There is no workbench API like that. Cycles is different because it was integrated as an add-on, but Workbench and Eevee are more closely integrated in Blender.
Eevee and Workbench would be difficult to make into add-ons, it’s unlikely to happen.
There may be some better way to achieve what you want, the fact that subclassing a RenderEngine works for Cycles is more an accident than something we support by design.
You mention that there might be a better way to achieve what I want. I currently use the draw_view3d() method of the GPUOffscreen which works in general but involves some limitations when in comes to speed and also in the further processing of the pixel data. Do you have any particular better way in mind? If so, I would be happy, if you would point me into the right direction.
It’s unclear to me which limitations you are referring to, but perhaps think of how they can be addressed directly with existing APIs. Exposing Workbench as a RenderEngine would not necessarily avoid such limitations.
There are two major limitations I wanted to look at if subclassing of the Workbench and EEVEE render engine would have been possible:
draw_view3D is rather slow when trying to access the 3D viewport for multiple camera perspectives.
another advantage of a RenderEngine subclassing could be, that there might be a workaround for the issue that we can’t access the pixels of the render results directly via Python at the moment. For each render you have to save the image data block to the disk and reload it first.
Probably neither of these would be helped by RenderEngine subclassing.
If rendering from multiple perspectives is slow, maybe there is some dependency graph update required due to changing the scene, maybe the viewport has to do some kind of reset because resolution changes, maybe not everything is cached from render-to-render where possible, etc.
Since I only can call draw_view3d as it is, I have no idea on how to narrow down if there is still room for performance improvement or if I just hit my hardware limits (which might well be). Is there any way how I can check if any of the things you listed causes a slow down or not? (Edit: Already checked, that depsgraph.updates is empty before and after the call)
Thanks for suggesting this function - looks good. I will keep it in mind and play with it, when it comes to Blender 3.0.0, but at the moment I am still at 2.93 (and below).
I didn’t check the exact cause, because I think it exceeds my skills. But @GottfriedHofmann pointed out that draw_view3d() used to be significantly faster before Blender 2.80. I did some quick testing on that and it turns out that the difference is huge:
Rendering 88 views from different perspectives:
Blender 2.79: takes 10 to 25 ms in total
Blender 2.80+: takes 500 to 650 ms
I would regard this as a bug and filed a bug report here:
I added you as a reviewer for the patch. I was told afterwards that this should usually not be done. So, I hope that is fine for you? If so, it would be great if you could take a look so that the fix can make it into Blender 3.0.