Currently Blender already expose RenderEngineType with no way to set it as DrawEngine. This module is more targeted for offline renderer rather than real time renderer. I have read the blender codebase and it seems EEVEE is a DrawEngineType. I don’t think there is a way to add this type of RenderEngine via python currently. I am planning to develop my custom real time rendering engine. Is there a plan to expose this as an api in the future?
You can attach your own renderer as a Python addon.
I have try it, there is a lot of time waste syncing blender depsgraph. This is fine for offline renderer since they are not expected to be fast for viewport render.
Without depsgraph, do you get good speed?
When making something public via an API it will reduce the flexibility that we have to change the internals of the Draw Manager module. Not sure it is the right time to do this. Also external drawing engine would still be responsible to generate the required IBO and VBOs from the result of the dependency graph. which is a very complex step that still require synchornization to reduce the amount of re-work. Similar as what would be needed when using the current render engine api.
Exposing the internal IBOs and VBOs wouldn’t allow that much of freedom as these are tightly build on how workbench/eevee works. This would not be the case when doing other for example different materials and you still need to convert the geometry to VBOs/IBOs yourself.
Is there a way to prevent eevee and workbench to create ibo and vbo, so at least there is no duplicate resource?
Eevee/workbench should not generate any IBO/VBO when they aren’t used. The issue is that extracting data from the dependancy graph and creating the IBO’s/VBO’s your draw engine requires would be very slow, what requires synchornization to speed up the process, hence would not solve anything that the current render engine python api can handle.
Do you know whether blender will internally iterate the depsgraph when I select a third party engine. I remember when there is many object instance, even the process of just iterating the depsgraph and copying the matrix data is already slower than rendering with eevee with the same scene. I suspect that blender internally iterate the depsgraph even when I select my custom engine. I only sync the vbo and ibo, when I detect the mesh data is changing. I use depsgraph.updates to check the mesh changes.
for update in depsgraph.updates: if type(update.id) == bpy.types.Object and update.is_updated_geometry: obj = update.id if obj.type == "MESH": mesh = obj.to_mesh() mesh.calc_loop_triangles() mesh.calc_normals_split() pykyuren.update_mesh(self.session, obj.as_pointer(), mesh.as_pointer()) obj.to_mesh_clear()
Internally it iterates over a depsgraph with an additional filter. I would not use python as core language for a draw engine. I would just use python as glue to another language so you can handle a lot of geometry.
Inside the draw manager generating the vbos/ibos is very optimized (multi threading, localizing data). Something that would be not possible to do using python only.
Can you profile what parts take the longest and see where a bottleneck is.