[Bf-committers] Blender game transition

[yul brynner]

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.