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 - [email protected] - 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 <[email protected]> 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 > [email protected] > https://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] https://lists.blender.org/mailman/listinfo/bf-committers
