Hello, I would like to point out that this new/updated API has a lot of overlap with a project I have been working on to bridge Blender with external realtime/game engines: BlenderRealtimeEngine (brte) addon[1]. I would love to see more of this project (or some of its ideas) get integrated into Blender and the stand-alone project made obsolete, and this proposal is a good step in this direction. I am fairly confident all of the OpenGL code in brte's view_draw could be replaced by the new API. Some problem areas we ran into with brte that should be taken into account for this project:
* Sending updates to an external engine can be a bit of a pain * The current tagging system is fairly fragile and prone to miss updates (e.g., I think removing an object from a scene does not tag the scene) * brte currently tries to build deltas to pass to external engines * This may not be as much of an issue for internal engines, but we'll need to make sure we don't miss things like material updates that trigger shader changes * Realtime engines like to get ticked/updated at a constant rate * Blender only updates the viewport if Blender data has changed (sometimes engines need to re-draw even if Blender is not aware of a change) * brte runs an update loop in a separate thread to feed the external engine with updates and issue a tag_redraw * An option on the RenderEngine to constantly call the new view_realtime could help eliminate some of these issues * brte has to play games with preserving global OpenGL state in order to safely draw into Blender's viewport * What are we doing to make sure engines issuing their own OpenGL calls are not messing up Blender? * Will we put code around the view_realtime call to protect state (could be slow)? * Will we document steps a well-behaving Render Engine has to follow to not break Blender (could be fragile)? * We can make use of OpenGL 3.3 features to minimize the amount of global state, but I don't think we can eliminate it. I would also like to see us explore combining view_realtime and view_draw. These seem very similar to me, and I am not sure why an engine would need to implement both. As the proposal expands, we will want to see if view_realtime is actually different enough to require its own callback. If not, I say we remove it and just stick to view_draw. Thanks, Mitchell [1] https://github.com/Kupoman/BlenderRealtimeEngineAddon On Thu, Dec 22, 2016 at 1:44 PM, Clément FOUCAULT <foucault.c...@gmail.com> wrote: > Hi everyone, (cross post from bf-viewport) > > I (Clément) and Dalai have laid-out the Proposal of the Render Engine API > that will be used to create new viewport "Engines". Things might change but > this is the general idea. > https://wiki.blender.org/index.php/Dev:2.8/Source/Viewport/EngineAPI > > We have also introduced a number of PyNodes changes that are required to > support custom GLSL for realtime engines. Thanks Brecht for his insights. > https://wiki.blender.org/index.php/Dev:2.8/Source/Viewport/PyNodeGLSL > > Insights from others realtime engine developpers are more than welcome :) ! > > The development of this will start as soon as possible in the 2.8 branch. > > Thanks, > > Clément > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers