[Bf-committers] Blender game transition

[Jacob Merrill]

I recently used ue4 engine for a paid project,
and I used blueprints, Looking back at old logic system,
it is much easier to use. but limited.

what I purpose is this,
I think that we should keep the logic bricks,
but there needs to be a few changes made.

1. logic substeps [ 0 - 10 or more]
similar to 'run first' but with 10 steps, so that events can happen in a
order.

2. sensor positive pulse is actually data [not just 'on']
I purpose that instead the flag for proccessing a controller is a tuple of
the data from the sensor.

3. Sensor Set Actuator
linking a sensor to a actuator sends it all of its target properties.
[ie ray sends ray.hitObject , ray.hitPosition, ray.hitDistance etc]
this way these properties can be used as input values in a actuator.

4.control mapping sensor -- when it fires it compares input string vs a
dictionary, if the string is on the dictionary, the key is used to put the
data on the output list linked to that key.
('WKEY') : ('Forward', index)
this list is then sorted by the index value, and doubles are stripped and
the index. creating ('Forward','Right') from [ ('Forward',0),('Right',3)]

(now we can easily create keybinding screens that generate input dictionary)

python users can take active input vs a dictionary to output a state, or
filtrr for inputs ie.
if 'Forward' in input:

and logic users can do
inputMap = str(Input)

and filter using the string
if Move == "('Forward')"----------and---------[walk state]


with these changes, we get the best of blueprints and logic bricks and none
of the drawbacks.



On Mar 19, 2018 5:28 AM, "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
>