What does BGE need?

Hello blenderartists,

I’ve recently began to work with Blender and am really excited to start to program with it. I think the integration of a game engine in a 3d modelling tool is very attractive!
So let me get to the point: What does Blender Game Engine still need badly? Personally I’d like to see a nice implementation of Kinect using Openni (there’s a python wrapper ) (wouldn’t that be so nice for character animations? ) and proper dynamic loading (which is essential for any (major) game nowadays ).
What do you guys think?

Greetings, Kratos

Yeah, you’re right. Except all the changes discussed there are part of the UI, not trully part of the engines/blenders capabilities, which is more what I’m aiming at. And (Not to be offensive, but) one should become a programmer to create a game I think, so theres just so much to improve in the UI.

No, you’re right. I myself am a programmer, so I see what you’re saying. As for the BGE’s capabilities, I think that it could use better lighting - GLSL is kind of slow; I’m not really sure how much better it can get, but hopefully, deferred / inferred lighting or whatever would help will get added. I think that it’s pretty good already - a general engine speed-up would be nice, but I’m not really pushing the bounds completely with my own skill.

The two things I’d like to see are the following.

  1. A preset physics for most common uses. Such as a person, type in the height, weight, etc of them and it will auto set the physics for them, if it’s an empty wooden box, or a full wooden box, a feather which would float down, etc. If there were like 12 presets, you could choose one of them for whatever physics you wanted.

  2. Multi-load scenes without python scripts (hard coded into BGE). The more scenes you add to pre-load the longer the loading time. Have an option like the Debug text, where it starts at say 5 seconds and counts down to how long it takes to load the scene, that way you can create an animation loading scene for that long of time.

The thing it needs the most (IMO) is a better/optimized algorithm for displaying polygons and textures, as of now you can’t add a whole lot of polygons and high-res textures so you gotta keep your game levels relatively small. Another great thing for it to have would be dynamic tesselation.

I am not all that familiar with the BGE though but does it support node-based materials? If not, that is another thing I would like to see supported.

Other than that I think it works really well.

@NinthJake - Yeah, the BGE does support node-based materials. That’s a good thing - you are correct, though, that the polygon / texture algorithm isn’t optimized enough.

About polygon/texture algorithm: Is it feasable to port/transfer it from somewhere?

Yeah, the bge lacks a way to access meshe data(create,add and remove vertices, deform, etc,etc,etc). What i would really like is not to have the bge script execution multithreaded, but at least to have it threadsafe. In additon an hard coded LoD would be nice (but i don’t know how this is done in other engines, so i don’t know if i said an heresy)

The polygon / texture algorithm could be ported from somewhere else, but it would have to be fixed anyway to work with Blender’s specific data types / functions (it’s not just ‘draw the polygons and textures on them’ - there’s a lot of other calculations to deal with… I think).

Do you happen to have a link explaining some stuff about this polygon / texture algorithm? Couldn’t find much about it.

Okay, a few thoughts:

  1. The BGE does not need support for Kinect/OpenNI. This just adds bloat to the engine. If anything, this is something for mainline Blender, not the engine itself.

  2. The BGE’s rasterizer’s ability to push polygons is really not a big issue. However, lots of polygons can cause issues elsewhere (Physics, lighting/shading, etc).

  3. Dynamic loading is getting better. If you have specific problems though, it would be nice if you mentioned them. “Make feature X better” doesn’t really help developers. :wink:

  4. The BGE could handle textures better. I have a patch that enables some OpenGL Texture garabage collection code in the BGE that Blender was already using. This will help old textures get removed from VRAM to make room for other textures. What would also help is proper DDS/DXT support so you can keep textures compressed in VRAM. I have a patch for this too, but it requires you to flip all your textures. :stuck_out_tongue:

  5. The BGE really needs better threading. Being single threaded is really starting to show and cause bottlenecks. However, it is not an easy task to multithread the BGE since no thought was put into threads when the BGE was initially made (not many people had multiple cores ten years ago). None of the developers currently have the time to address this.

You’re right, Moguri. Kinect isn’t really high on the to-do list, and I would assume that Kinect can already be used with the open library and some Python to C++ function checks. Would better texture handling processes make the BGE draw (textured) polygons faster? What about the logic processes - can they be optimized any more than they already have been?

EDIT: Also, threading would allow the BGE to take advantage of multiple cores, huh? That would help to make a faster game engine, at least for logic processes.

@Moguri: Thanks for the clarifying post Moguri. I’m not trying to ask for feature X, but trying to ask where I could (try to) be of help. And BGE does not need support for Kinect, but Blender should. I wasn’t clear on that.
I read around a little and came to the conclusion dynamic loading is a general problem (I believe to specific it is that to dynamic load a object you have to put it in a seperate blend file) as well as multithreadedness indeed.

Well, it is hard to say. Blind optimization really doesn’t help. If you have a sample blend file that highlights a performance issue, then please share it so I can try to find the bottleneck. Now, putting 5 million polygons in a scene and wondering why it’s slow is not really a helpful test file.

Dynamic loading is only useful for objects in other blend files, otherwise you could just use addObject. Also, it could use some threading and there are still a few bugs with it (the big one being with lights).

What about a four core threading system? Where you can have four different things, each per core.

Example, 2 cores for loading screen, 2 cores to load first level.
1 core for loading screen, 1 core to load first level, 1 core to load game over screen, 1 core to load animation scene.

  1. you’re right. Python is here to allow us to go stuff not natively supported by blender

2)i never had problems about poly number, so about this i can’t really say anything :slight_smile: But for sure i can say that there is no way to generate meshes (i was thinking of generating dynamically a terrain mesh, and right now i would need to do all the calculation for generating all the vertices informations, and than i would need to store this informations into a blend file, and than load it with LibLoad[the bpy is not supported in bplayer])

3)Dynamic loading right now is already quite interesting. Unfortunately it lacks of documentation (i had to check the source code to find that LibLoad can accept python file object as input). In addition would be nice to give the possibility to load the scenes as overly scenes and not only throw all the object in one scene into another (while this can be useful, so it is not to be removed). Few time ago i had other things in mind, but right now i can’t really remember.

  1. This would be nice, btw i never had problems with textures(but i didn’t really made serious testing). Btw with your patch for soft shadows, and the incoming inferred rendering of Daniel(ps: is he your brother/relative?) i think that the bge doesn’t have big problems on the rendering side. Maybe a better physic would be nice (i saw problems in small detections, is missing a ragdoll system, is quite difficult to have good collisions on a character animated). in addition your gsoc is really interesting, if you’ll get to bring it in trunk will be a great step ahead in animation!!!

5)I have a lot of problems here.I’m using python threads not to have a better performance(due to the gil) but to allow the rasterizer to do his work without waiting for a script to terminate. Obviously i’m running into many problems with accessing order to data, and the “casual factor” that multi-threading brings. Even if i created a thread class that has the terminate method, after running the bge 2 times it crashes(i think due to alive threads[i didn’t opened a bug report since it would be like complaining that my bicycle can go on water, this is not a supported feature],even if i try to terminate them before the game end) I had to disable the importing of obj files at runtime since it was crashing the bge on LibFree (don’t really understand why this 2 things were connected). I’m not such a good programmer to help porting the bge to multi-thread, and i really must say that i can’t even imagine how the system could be handled… The python problems with multithread are not even helping in this. Maybe releasing the gil is possible when C++ functions are called?

Other things:
your system for “world” controllers (i don’t really remeber how you called them) would be nice. I think that the node logic is REALLY REALLY REALLY REALLY needed, with this logic brick system i feel really constrained… A simple way to reuse setups would be really nice (but by now i’m writing an add on to store all this data in an xml and to make really easy to share script set-ups, or to have a directory of set-ups (dynamic terrain loading, rag-doll, movement, shooting weapons, life bar, hud, minimaps) that can be added to our game with only 3-4 clicks)

A better way to handle priority run of scripts would be nice. Why not put 10 levels, instead of only 2?

There are so many aspects of bge i haven’t already touched, but i’m amazed about how it is great. Obviously it can be better, but you devs are really doing a good job. Another thing i would really like about the bge is maybe a C++ Api and a bit of documentation about how and where to start, right now i would like to handle little tasks, but i really can’t find a point to start from…
(last think: there are hidden module in blender :S like the noise one. I spent 4-5 day to implement a perlin noise python module written in C(i needed to run it many times, so i needed speed), and after that i discovered[read as: campbell said me] that there already was a module inside blender…)
(really last think: with python we can’t access the list of controller/sensors/actuators links. It’s one of the last problem for my add one, i don’t know how to find this informations…)

Last of all: keep you awsome work devs, we love you :wink:

@fayt: the threading is a bit more complex than this. You have to bother with locks and unlocks, deadlocks, priorities in accessing data, an lots of other issues :wink:

Pool our money together and hire a couple Programming Guru’s to do it :stuck_out_tongue:

The problem is that e new architecture should be developed. Like the new shader system, you can’t just tweak something, you need to change a HUGE part of the code, and for this for sure the bfoundation wants someone trusted, that will follow blender in future and that already worked on it. In addition, he/she should have plenty of time (or it will be done by the 3012 ). This is not only writing code, this is thinking on what code to write, and how. A bad design will bring to HUGE pain in future, while a good design will bring a bge completely extendible in future. That’s absolutely no easy. I think moguri know the problem and will do what is needed, on my side i don’t feel i have the knowledge to give suggestions :wink:

One thing I really want to see is shadows from directional lamps (sun lamps).

BGE needs only one thing: More Coders!
I hope see more developers soon, maybe after all “Blender 2.5” works =/

But i really like if we have a new round of optimizations in Shading/Light before that.
As moguri sad, BGE handle a lot of polygons, it´s true. I say, try make a lot of materials or a scene with a lot of lights… Is Game Over to you :smiley: !
I know, lights no one engine can handle good without a defered render, but we have really problems in that.

A good work in LOD (for Physics and Graphics) would be nice too. Is impossible make a good large level today without so much python code.

In code area i think is the time to remake the Logic Bricks in a Nodal style.
Bye! :smiley: