So we welcome the intergration of the video texture plugin into the BGE, but we need to get serious about bringing in the important step which is optimizing the BGE. The user can only do so much to optimize his game, so we need you, Ben2610 to seriously consider getting the BGE the needed optimizations that it would take for the BGE to run much faster.
As first steps
1). Frustum and Occlusion culling, a huge game can run maybe twice as fast graphics wise if none of the objects the player can’t see are rendered, for an experienced programmer like you this shouldn’t be too hard.
2). Ability to easily have an object in the active layer control actuators in objects added from hidden layers, simply by connecting the active layer object’s sensors to the actuators of the objects in the hidden layer. This allows for optimization in a way you can replace tons of like-objects with a single object from a hidden layer and a single object’s sensors controls the actuators in the added objects. Only one set of sensors is checked, greatly speeding up gameplay.
3). Physics culling, option to disable physics of objects occluded by other objects or not seen based on a margin on how far it’s hidden from view. This will be a tougher thing to implement, I suggest the first 2 suggested optimizations are done first.
Look we love all the additions you and others have done for this engine, but we need optimizations like these to allow for huge games and quiet the stream of comments saying the BGE is very slow, many have asked for stuff to increase the performance of the engine. So Ben2610, can you do this, many thanks from many members here if you take this task to high priority so the BGE can be much faster and much better for huge games by 2.50, ready to recieve the possible tide of new users.
3). Physics culling, option to disable physics of objects occluded by other objects or not seen based on a margin on how far it’s hidden from view. This will be a tougher thing to implement, I suggest the first 2 suggested optimizations are done first.
I have to disagree about that. I pretty sure that the physics engine already “disables” physics on a object that is not moving (aka: the sleep function). I don’t believe that you should disable physics when an object is “far way” or hidden from view. You would get unwanted results. For example, lets say you brake a box and the pieces fly off to the side of the screen. Now if the player don’t move the camera for a period of time and then turns to the face some of the broken pieces, the pieces would still be in the air and look very unrealistic and unnatural. (Hopefully, that was a clear example).
Of course, that’s only true if your talking about physics culling, not object culling - which are different.
Well like I said, any sort of physics culling would be tougher to implement than the top two suggestions, so the first two would best be done first anyway.
I express reason to get most, if not all of this done by 2.5 (allows 6 months at the least) so we have a massively improved BGE to go along with the huge rewriting effort going on in core areas of Blender.
a compiler: the converter is slow on big scenes, so maybe providing a way of saving pre-converted data in some format and loading it with the blenderplayer, it could also ease standalone closed-source distribution since the python scripts would be compiled to bytecode and blender will not be able to read the compiled data for editing purposes (escencial data will be lost in the process)
edit: other (optional) features of thecompilar may include conversion of textures to .dds format, mipmap pre-generation, some sort of data compression to reduce the runtime size, etc
Speed is not the most pertinent issue at the moment. We need to establish a robust developer community, and to do that we need the current developers to both write, and advertise better documentation.
I don’t know which “we” you represent, but you should all try to understand the root of your current problems, before you start clamoring for specific solutions.
1). Frustum and Occlusion culling
I think the BGE does that already. Can anyone confirm that?
stream of comments saying the BGE is very slow, many have asked for stuff to increase the performance of the engine.
I expect that in most cases the people who complained were novice users who:
Don’t understand low-poly modeling
Don’t know how to use python with the brick system effectively (therefore unable to reap full logic performance benefits)
Use 1600x1200 textures on everything
So Ben2610, can you do this, many thanks from many members here if you take this task to high priority so the BGE can be much faster and much better for huge games by 2.50, ready to recieve the possible tide of new users.
And how exactly would this increase in the user base translate to an increase in the developer base?
If there is anything to be learned from the history of BGE development, it is that “engine features”, such as speed, are not what ultimately attracts most developers. A robust developer community and good documentation relating to the source code is much more likely to do the trick.
Since i’m really tired of listening to people whining about the python integration/codebase without doing anything helpful whatsoever. i’m working with moguri on cleaning up the python API and making stuff more consistent and easy to use/develop/expand. if someone with c++ knowledge wants to help, PM us.
@Social: Ben made a comment in a previous thread that the culling code was in there, but it was commented out and shouldn’t be too hard to add back in.
@Cyborg Dragon: I can’t think of any engine that has any sort of physics culling… it’s just not natural. Just because you can’t see an object doesn’t mean that it shouldn’t be able to react to physical forces. If you need to do some sort of “culling” you can easily write your own scripts that remove or disable physics on objects that are far away. The engine itself definitely should not do this, and the script really wouldn’t be that hard.
@The Tone Of This Post: I feel like there’s kind of a “demanding” tone to this post. We need to remember that Ben and the other coders do all of this stuff on their free time. I know this is stuff we WANT, but these guys aren’t being paid, and asking in this kind of tone seems counter-productive.
by the way, the new python api will break compatibility with all the scripts made for the old one (but since the backend code is almost the same they are really easy to migrate, some stuff could be even be automated, and other stuff could be simplified by the new methods introduced),
Almost everything in 2.50 will break backwards compatibility in order to use much better designs.
The Blender Game Engine is plauged with glitches, bugs, problems, and of course, in mid-sized game projects, the tedious repetitive action of deleting hundreds of clones of images and materials.
Before adding new features, it’s important to fix the ones that we already have.
After that, managing a game project in the Blender Game Engine can be a bit of a nightmare, although the new linking and grouping system is a huge leap in the right direction (in some projects, datablock clones are inevitable, and are a huge problem).
well thats not the BGE’s concern, that is a problem with blender itself, but 2.50 will dramatically improve the workflow, or at least allow us to do it
Heh, you should try to understand what the people are whining about first. The fact that some property assignment facilities were implemented as functions is not the critical issue; the fact that there is no support for proper OOP (independent of the brick system) is.
See, this is helpful to mention, because now you can focus on addressing more than just trivial syntax issues.
…and you’re welcome.
if someone with c++ knowledge wants to help, PM us.
I know C++, but it’s going to be a little hard to help you, because I don’t know how the python system actually works in the BGE. Actually, I can’t even tell where python execution initially starts within the main loop.
Maybe you could use your non-whining “can do” attitude and write documentation that explains some of the main classes and how they work.
…I think all our “whining” has made cyborg_ar tired to the point where he can no longer grasp that basic concept.
Anyway, let’s try not to overwhelm him with our “whiny” concerns; he has code to write.
Well Zaghaghi has been working on getting the GE working with RNA(see the mailing list). It may be quite possible that when 2.50 is finished it will make it a lot easier for GE developers to very easily write new tools and interface to drastically improve the game engine.
If you really want to help you can do it without much problems (i dont even know 10% of the api, i learn as i code :)), but well you may not have enough free time to play with the code, its fine then.
@cyborg_ar. Seeing as as you’re working on sensors can I ask for a tinsie new functions to complement the .isTriggered()? Currently if you ask .isTriggered() you get sent a True twice, once when its activated and once when its un activated, would it be possible to break that up and have .isTriggered() and .isUnTriggered()? If you really cbf with that you don’t have to if you don’t want to because it can be avoided by asking “sens.inTriggered() and sens.isPositive()”.
