[Bf-committers] Blender game transition

[Ton Roosendaal]

Hi Yul,

Thanks for the writeup. 
It's a lot of info, I will make sure it gets serious attention by the code quest team in April.

-Ton-

--------------------------------------------------------
Ton Roosendaal  -  ton at blender.org   -   www.blender.org
Chairman Blender Foundation, Director Blender Institute
Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands

> On 19 Mar 2018, at 13:28, yul brynner <you.le at live.fr> wrote:
> 
> Hi, as suggested by hackerman, I share my thought/plans draft for interactive mode:
> 
> 
> Interactive mode ideas/proposals:
> 
> These ideas doesn't include logic changes because I don't know UI code. If developers wants to change logic,
> this should be done before what I propose.
> 
> So as far I understand, the bge loop works like that:
> 
> - First logic, animations, and physics are updated
> - Then render is done
> 
> I propose to progressively insert depsgraph DEG_id_tag_update (python API + new functions to replace old ones):
> - in the first step of the pipe
> - just after the the first step of the pipe BUT before render
> 
> to have the ability to use blender power (like modifiers update in realtime I guess) inside BGE.
> 
> I think this will allow to remove a lot of BGE code (which is currently not so important), and this would allow the volounteer
> core coders to use the code they are familiar with.
> 
> BGE can remain coded in C++ (which is a big advantage imo because new coders can learn it more "easily")
> 
> and stay a separate "small" entity beside Blender, but using directly Blender code.
> The fact BGE remain a "separate" entity doesn't prevent that we can use directly Blender code and
> have something which is however very tied to Blender.
> 
> The advantage to keep a separate entity is that once we have a module owner (not me because I'm too newb and I don't want to be
> the leader of anything), we can work on a "small" pipeline, which is much more easy than to work on entire Blender code I guess.
> And we can work with more freedom if we keep a separate entity.
> 
> About custom classes for BGE, like KX_GameObject, this can be kept imo for now. KX_GameObject is just an Object with custom attributes and functions.
> For example, in my branch, when I want to update KX_GameObject matrix, I use "KX_GameObject's Object->obmat". KX_GameObject is just the container of Object.
> But KX_GameObject currently contains other attributes and functions which are currently needed to make BGE code work. So we can't use directly Object
> in a first time. Keeping in ming that the goal is to reuse maximum of Blender code directly, maybe we could avoid to use KX_GameObject and use directly Object,
> but more important changes have to be done before.
> 
> To make the BGE code more tied to Blender code, I propose to first:
> 
> - Write a new KX_GameObject API with Blender code.
> . This API just needs 2 functions: Add and Remove object
> . This API should use BKE_object functions (I guess) and depsgraph DEG_id_tag (I guess too)
> to say to the BGE viewlayer's depsgraph that a new Object has been added/removed.
> . The function to update depsgraph (BKE_scene_graph_update_tagged(eval_ctx, depsgraph, bmain, scene, view_layer);)
> is called just before render in my branch. Then a complete eevee's render loop is runned (DEG_OBJECT_ITER is runned to populate the render
> cache with the needed objects, then the scene is drawn, then we swapBuffers and start a new frame).
> . We have to find a system to erase all replicated Objects at BGE exit and restore original Object state at BGE exit. A class to save/restore states
> can be done.
> - Replace MOTO (math library with BLI_math).
> ..........
> And always keep in mind that we have to reuse maximum of blender code.
> 
> What is the current state of my branch?
> 
> - I abandonned my previous approach to integrate eevee's render into bge (which was based on DRWCalls (but without using depsgraph)
> - In the current state, we can run 1 scene, move objects (updated with depsgraph).
> - We can replace scenes.
> - A part of VideoTexture is working (like play video on a textured plane)
> - We can use an important part of logic and physics.
> - Render culling is directly done by eevee so a big part of what is in bge code regarding render culling can be removed,
> and another part has to be replaced with the result of eevee's culling test result (Set KX_GameObject culling state according to eevee's
> culling test result to perform some operations like reduce logic, animation, and physics activity when the objects are culled).
> - We have the ability to use blenderplayer and export games, which is a big advantage. As I said to Ton Roosendaal, if we remove the ability
> to export games, it's a bit like if we'd removed the ability for a cycles artist to take a picture of his art and share it.
> 
> What is the current state of BGE code?
> 
> - I worked several times on old official BGE code, and in UPBGE. UPBGE code is much more fun to code for me (a newb) because Panzergame
> updated a big part of the code with C++11 standards. Really, now, for a beginner like me, it's really easy to write (and understand too!) some code without the constraints
> of old C++. Coding in C++ is almost as easy as coding in python.
> 
> - Panzergame also fixed tons of bugs which are currently in the BGE official bug tracker.
> 
> - The eevee's integration code in bge might be only ~300 lines in draw_manager I guess, nothing in draw_manager_data, nothing in eevee.
> 
> - I begun to reduce the codebase removing a bunch of files, but there are still many unused files that we can remove.
> 
> - Some reorganizations are needed but this can easily be done.
> 
> - I think some renaming stuff is needed too to make the code more readable, and it would need the help of someone who speaks well english.
> 
> What are the advantages of this plan:
> 
> - It offers a maximum of backward compatibility for logic scripts.
> - We keep the ability to export games.
> - I think it respects both BGE community (game makers) and the wish expressed by Ton to have a code more tied to Blender,
> using Object and depsgraph.
> - I think it should be possible using the same system to render clay shaders, or even include in the render loop some elements like
> armature drawing if we want....
> - A true game engine is much more powerful than something which would allow a small level of interaction.
> - This is already a concrete proposal
> - In my newb perspective, it is easier to refactor than to rewrite from scratch.
> - Using UPBGE code as base should make it easier to BGE developers to contribute on it.
> 
> What would need this plan?
> 
> - The core developers contribution to put all in place and write the base APIs with depsgraph (I'll maybe begin to learn it...)
> 
> BUT I'm not opposed to more important changes if other coders have a better plan (including the ability to export games).
> 
> I code on this branch if you want to have a look: https://github.com/youle31/EEVEEinUPBGE/tree/experimental5
> 
> youle.
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers