anything about getImpulseForce?
Do you have a resource link for the patch? I’d very much like to see it 
The work flow benefit is not isolated to the bge. Given that the bge copied blender data, which is available from the python API, another engine could replace it without any users knowledge. That’s the part that is important if it feels like the engine, that’s what matters
It would be interesting to see if the BGE could indeed be replaced with a system comprising of OGRE (Graphics), HIVE (Visual Logic), and Panda3D (Python Logic) in such a way where people barely notice anything with their projects (or at least get them back up and running rather quickly, especially very complex projects like BPR’s Wrectified).
If that ends up being possible, then I think most everyone here will embrace the new system and not even miss the BGE (especially if it offers things like control over more systems provided by Bullet and a much larger list of graphical features).
I’m happy with the BGE.
I still find limitations to be my own and not the engine’s.
That being said, I wouldn’t say no new features.
I agree. Although whatever engine comes next, logic bricks will most likely be retired.
One of the more challenging aspects is directly reading the Blender file format (currently this is what I’m working on…). The blend file is literally a raw memory dump of the data you are working on so it’s not meant as an interchange format, and thus not favorable to external manipulation.
The easy solution is to use Blender to read the file format like the BGE does, however using any code from Blender (to read the data structures) will render the game engine GPL. Sadly, this means the KISS/DRY rules needs to be broken and a permissive parser needs to be rewritten, which is much harder than it seems. Blender itself can be thought of as a library for manipulating Blend files which means creating a parser is like recreating certain aspects of Blender and Blender is a big program. To make things more difficult, the specifics of the blend format is ever changing. AFAIK, there are no complete external parsers; GameKit’s parser was not completed.
The other alternative is to use a different file format (e.g. FBX), however this still faces the same issues. Animations and rigging seem to be the most challenging.
Keep in mind, this new game would not officially be supported by the BF so that might change the community dynamics…would it still be hosted here?
Hm, I see the issues you face. A possible solution would be to keep the engine GPL and make the actual standalone player a specific license, but you’d still need to write that blend file parser for that, or else it’d just be the same as the engine we have now (GPL through and through).
Maybe instead of parsing, the engine could be made to push all relevant blend file data out silently? Like, you select the “Push To XEngine” button, and then an add-on would output a GLSL script for the materials (node or otherwise), .py files for built-in text resources, .dae files for models and animations, some kind of format (maybe just XML or JSON or something) for nodes, and so forth? I think that’d be easier to do than actually writing a parser, but no telling if the model file format will support everything Blender can do. OpenGEX supports a bit, but there’s no official Blender plug-in yet… There’s also assimp, which seems to have no problems importing blend files, but I don’t know what you can do with it (I assume it’s a library or something that can present the data in the blend file to you in some manner).
I assume you mean if the new game engine would be adopted by the BF - I doubt it would initially, but the whole “interactive play mode” that was proposed for the game engine seemed to be in response to the engine not receiving as much love as it really needs. If your engine is as seamless as the BGE is now, is more powerful and easy to modify, and doesn’t have the GPL issues, then I think the BF would be interested for sure. I think it could be adopted by the BF given enough traction and development time (I’m just guessing here). I doubt it would be packaged in with Blender, since it is a whole engine, but it could receive a link and be available for download on Blender’s homepage (again, just guessing).
EDIT: @Ace - I don’t know if I see the need to push Panda into a potential new engine - it’s already an entire engine of its own. It’s another dependency to keep up with, and one that’s out of the hands of the developers of the engine. It would mean wherever the engine goes platform-wise, Panda would have to basically already be there first (unless the devs modified Panda’s portion).
That’s the same with any engine. And typically speaking, if you need support for something you add it yourself, or someone else does. All we do in adopting another engine is increase the chance of someone else doing so, and less development work.
So now we are not only compromising the BGE but talking about .blend format being obsolete as well…
I wasn’t familiar with how bad format the .blend actually was. O.o I was blaming Autocad for it but no wonder the industry doesn’t want to support .blend if it’s just a memory dump (interlinked binary data blocks?). Why can’t it be parsed into something sensible? It’s not exactly hard to format data AFAIK but oh well, more rewriting. Just makes me thing why they can’t make this stuff properly to begin with. FBX is not bad I suppose but doesn’t exactly correspond to how Blender handles certain stuff (like shape keys) and also is proprietary.
Having tried various 3D modeling software I don’t think there can be format that supports all the quirks which makes things frustrating.
But for Blender I’d see them best use ASCII format with tree structure that is easy to import/export. I would actually give up storing images and text blocks inside the container (store relative paths and improve external library managing features to keep things tidy) or if it’s necessary it could use .zip architecture in packaging for easy access outside Blender as well.
Personally I only use the Blender Game Engine for Python logic experiments only. Making a game using the BGE feels that you have to make a large gamble on whether or not it will work on a player’s computer. Right now I am contemplating writing a 2D game with the BGE, but it is nothing big.
Nobody’s talking about compromising anything. We’re talking about the future of the engine - what could be done to push the BGE to be a full-blown game engine (and if it’s worth it).
Motorsep has mentioned in the past that he wanted better importing from Blendeer into Doom 3’s engine (I believe it’s used in this video). I’m guessing it’s not tied into Blender at all currently, which is something to consider.
Moguri’s mentioned looking into merging Panda3D with Blender to the point where you couldn’t tell it’s not running the BGE in the back-end. I personally have some concerns about Panda overall that may or may not be blown out of proportion.
EDIT: We also could go another route of “merging” Blender in with another engine.
Other developers have expressed interest in working on the BGE as it is, though denying this could prove the opportunity to push the BGE (or another engine in the place of the BGE) to a whole new level.
And now we have Mahalin’s proposed engine, which sounds like it might soon be ready for testing, which is nice.
@Agoose - I suppose, but if something is needed and it hasn’t been done already in the engine’s lifespan so far, in my opinion it’s not likely to happen (an Android port, for example). Also, I’d guess it’s a lot easier to add support for something to your own code-base than to learn another engine’s code-base to add support to it.
Personally, if we’re talking about tighter integration with an external engine, then I’d probably back Torque3D. Based on its current development, I honestly feel that it’s the closest open source alternative to a Cryengine or a UDK. That is if we’re avoiding the GPL. Even stock, it’s pretty powerful. And since it’s released as MIT, there’s no concern for having your game “infected” by the GPL license when you decide to distribute. I think the biggest problem is that it’s viewed as a programmer’s engine, which in a lot of ways it is, but it doesn’t have to be, especially if the component system that’s being developed gets added to trunk. The other problem is that the official version of Torque is currently Windows only, but I believe that the Linux/OpenGL port is nearing completion. In talking to one of the developer’s on the steering committee, I’ve realized that he thinks the same thing I do, that a tighter integration between Blender and Torque would benefit both communities. If anyone’s interested in the conversation you can check it out here:
http://www.garagegames.com/community/forums/viewthread/137721
Now, granted, I am probably in the minority on this matter, as Torque doesn’t seem to get a lot of love around these parts, but I figured I’d throw my 2 cents out there anyway.
Mahalin, What parts of Gamekit’s parser are not completed?. I checked it some time ago using the fileinspector and I remember that it worked well. Perhaps, you have to generate a new blender.h updated up to 2.71 (the last generated using FBT tools in gamekit’s projects i think it is 2.64).
The blend file format in general is stable in terms of the DNA/RNA. I mean it’s fully backwards and forwards compatible. However, it was designed specifically for Blender so it makes sense that other programs wouldn’t consider supporting it. Personally, I would’ve like to see an ASCII version so it could be used with VCS.
One thing to keep in mind is none of the pre-existing engines are likely to turn into the BGE. What I mean is they all already have a data structure they use. For them to directly support the blend file format like the BGE would probably mean rewriting/refactoring a huge chunk of it. Not to mention, they all virtually use LUA except for Panda3D.
Hmm, maybe supporting FBX will allow easier support across multiple engines?
As for my engine, give me another month or so. Anyhow, I’ll save the details for a separate thread.
@LordLoki
I forget…I looked into it sometime back; I may be wrong. If so, GameKit might be a good start to replace the BGE. You could replace the parser with the assimp library. TBH, I think GameKit may the best bet for a BGE successor compared to moving to other established engines.
Reading through this, it sounds like another developer meeting could be in order, because I don’t exactly see a unified plan for how to push game development with Blender forward.
Some argue to clean up the BGE code so it can be developed at a much faster rate, some argue for their own engine, others call for replacing the BGE with an embedded version of Panda 3D (to where people run their old projects and can’t tell that it’s not the BGE running them).
I think we need to at least take into account these points.
- -What solution could be done for people to get their projects back up and running as soon as possible?
- -Is it possible to replace the graphics engine with something more established (like OGRE)?
- -Converting existing logic brick setups to use the HIVE system, this means the removal of the logic bricks window type since the node editor will now be where you do the work in.
- -Is it possible to do things in a way that allow more flexibility in terms of selling a game as a commercial product?
- -Methods of testing, do we keep the ‘press P’ system for play in the viewport or will we have a new button to launch an external player for all testing?
If these things form the centerpiece, then we could potentially have a much better engine to where people don’t even miss the old BGE itself.
My thoughts exactly,
I love the bge how it is,
however frames per second vs Polycount is an issue (rasterizer or render?)
Bullet physics wrapper needs redone( it’s a little buggy and I am not sure if it could be made faster)
a few items need fixed in the python api
and if I can do the same stuff in hive, at the same speed as logic bricks, I would do that for sure,
Ogre is overengineered
Its good, that there is version 2 in the works where outdated stuff will be removed, but i would go with a render interface where you could plug a lib and later write your own (to save time in production).
Im not really a fan of the nodes and stuff, a good api with doc and examples will be better and after that maybe a nodes system if its needed. Some indies and stuff may prefer to use some node logic system, but i would say, that what they need is more like a build in tool and functions to ease their development process.
Edit: Perhaps Gamekit could really replace the bge if taken.
Support and patience. If there’s no support to cleanup the BGE than it won’t happen. It’s as simple as that. And I don’t think we can say there’s a lack of support. It may be not as much as we had hoped, but altogether we can be optimistic. When I look at the efforts being made to reorganize the code, I’m really impressed. Also a lot of effort has been put into bug-fixing the last three months. Then to me it would seem a bit disrespectful to say that BGE development is going into the wrong direction. We can only be grateful that we got the support of the Blender Foundation in hiring Moguri for this work. Nonetheless, still a lot of work needs to be done. But he can only do so much. So let us as a community not only express our gratitude for the direction it is going but also ask the Blender Foundation to continue supporting for another three months or maybe more. Of course we should also continue to encourage developers to contribute if they are willing to do so. But if we say that the BGE is a lost cause, to difficult to optimize, to old-fashioned, etc. , how is this encouraging? How would anyone be motivated to remove the obstacle if everyone would keep saying: “Don’t go there, there’s an obstacle”?
Also, in my opinion, even if the BGE would stay problematic in some cases, it’s good enough. In my own opinion game development with the BGE is possible at a reasonable level. That is, if all important bugs would be fixed. So don’t throw the baby out with the bathwater. (Because I’m sure I’m not the only one who cherishes the baby).
Modo, Cycles, UE4… One of the clear trends in the 3D industry these days is a movement towards a more node-based workflow for materials and shading. This eliminates the need to have an abundance of specialized shaders (depending on the node types given), and allows almost anything to be possible (imagine having terrain-like material blending on all objects like you can do now). It doesn’t stop with those three examples, some of the most sought after shading plugins for Unity use a nodal system.
We can’t swap out the graphics engine for OGRE unless it retains support for the material nodes, because it allows for anything from terrain blending to fresnal effects to blended box mapping.