[Bf-viewport] [Bf-committers] Engine API

[Mitchell Stokes]

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.clem at 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 at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-viewport/attachments/20161222/43c42293/attachment.htm