That would be cool, and I agree that most technology would already be available cleanly integrated (HDR etc. at least in Ogre, don’t know about Irrlicht…). Though I could imagine that “integrating” would almost be an inhuman task. I mean how should an integration of another graphics engine work anyways?.. since blender is WYSIWYG in all matters, one would need to port all modeller tools, game mode, logic, interface actions, library etc. and exchange the existing variables with the ones from ogre etc. - at least I think that… expect I am wrong and there is an easier way to integrate a new graphics engine… ?
Well, I’m not clear on the exact details myself, but looking at the source, there is a distinct set of converter classes (in source/gameengine/Converter) that seem to “convert” blender data into something that the internal game engine can actually work with.
So, I guess rewriting that part, to convert blender data into something that OGRE/Irrlicht can work with, would constitute a good part of the overall effort.
Not to say that this is easy (if it was, I would do it), but it would be the right thing to do, from almost every logical perspective:
- We get the latest and greatest graphics features.
- We continue to inherit more advanced features as they become available.
- The developers can focus on things that someone else didn’t do already.
blender is WYSIWYG in all matters
Only in GLSL mode - the game engine looks very different than the 3d view in multitexture for example. So whatever is porting to multitexture could theoretically port to OGRE or Irrlicht.
The thing about procedural textures is that an infinite amount takes up almost no space. Texturing the world with images either will take up many gigabytes of space, or will have tiling (which looks awful in my opinion). Also I want to use procedurals for the clouds, something like Alan’s Cloud Generator (http://www.blendernation.com/alans-c…enerator-beta/) only in realtime.
You can use GLSL to make procedural textures as martinsh did in: http://www.youtube.com/watch?v=Ajg8Xi9hGVE&playnext_from=TL&videos=EIX6Eboo2CQ
Of course Procedural textures is not volume render and only that don´t make volume clouds, but you can use slices to do that : http://www.youtube.com/watch?v=qdRIJpBFGsU&playnext_from=TL&videos=wZ9UVJaul-s
I think that if a developer have knowledge and time to add Ogre3D in BGE he should use that to improve the BGE working in fix the many problems that we have and add new functions. But if we had a BGE working perfect with Ogre3D it would be nice too.
Bye! 
I’ve read in some 2 year old topics that the porting of the GameLogicBricks integration made very huge problems. I wonder if this was the showstopper for Ogre integration, because this would be a shame.
The more I dig into BGE scripting myself, the more I see how limited the Bricks really are, and even very basic things require additional scripting to actually get the things done you want 'em to be. For fast prototyping it’s very nice and useful I must admit and it also helps to get to know technology better for beginners…
Still if there was the choice - I would suggest to reduce certain LogicBricks or remove some of its features completely to achieve compatibility in favor for a better rendering engine/mature features.
(Otherwise I agree the poster above: if BGE Graphics engine/features matures like Ogre in future, there is of course no need for Integration. It’s not that I think the Blendergame Graphics Engine is bad, just some optimization and features lacking)
I’ve read in some 2 year old topics that the porting of the GameLogicBricks integration made very huge problems. I wonder if this was the showstopper for Ogre integration, because this would be a shame.
Hear hear.
If Ogre could be used in Blender then all my problems would disappear! Well, all my BGE-related ones anyway.
How about Unity? It uses a dialect of Python called Boo. And if you don’t like that it also supports JavaScript! You can make standalone apps and executables, too! :eek:
Well, that’s not good; the logic subsystem should be completely independent of the overall rendering system.
I don’t know… I mean, graphical fidelity, for me personally, is less important than robust logic programming facilities, so I don’t really care that much about OGRE.
However, I think that OGRE integration would not only free up developer time for logic work, but it would also do something to reorganize the base engine architecture into more manageable chunks.
There was an interview with Campbell (ideasman42), where he refers to it (correctly) as a “tumor of a game engine”.
Here it is: http://www.blendernation.com/interview-with-campell-barton/
… Campbell is awesome.
@Unity: it looks nice, and seems to be very optimized when I tried it out. On second view however, if you want to make a serious Game and port it onto Consoles e.g. for developing Wii games you must pay additional 30.000 bucks for licensing, I’ve read on devmaster that an iPhone license costs additionaI 1500$ added on the 1500 of the “Pro”-Version.
However it sucks that the paid(!) developers don’t care themselves about features like water shaders or normal mapped terrain, which should be present nowadays if you pay for an engine… i mean: it’s 2010 and these things were missing for 2 years now, still no developer cared…
It’s not that I think the Blendergame Graphics Engine is bad, just some optimization and features lacking
How does optimization compare between the two? Having never come across a scene which was present both for the BGE and for OGRE, I have not been able to tell how much faster OGRE is.
@optimization, i can recall at least 1 example: Unity seems to handle really large terrains without hiccups, say you have a terrain full of grass, flowers, bushes and trees: then it “converts” the far distance trees into 2D objects. And you won’t realise it, because it’s looking the same as before - not like blob-trees in TES:Oblivion… ;-). I don’t think this works in Blender very well 
I’ve also no idea how Ogre manages that…, although the old “Dwarf” demo has lots of grass, but the performance did not seem that well to me…
Unity seems to handle really large terrains without hiccups, say you have a terrain full of grass, flowers, bushes and trees: then it “converts” the far distance trees into 2D objects.
Unity is not on my list because it is not Open Source as far as I know. If there is an open source version, please correct me.
Since Moguri’s project involves having a fairly complete GLSL implementation along with those shaders accessable through the UI and seen in the viewport then by that time the forum’s GLSL experts could provide high quality shaders for use in games to increase their graphical quality.
It’d especially be neat if part of Moguri’s project involved being able to add custom coded shading and material animation options to the existing GLSL features, at the point where his project is it might be even less work than a full OGRE integration:spin:
at the point where his project is it might be even less work than a full OGRE integration
Getting the features of OGRE is just half the story - the other half is optimization. From what I understand, the BGE has a long way to go on that front.
The BGE is as far behind on performance as it once was, but it’s still behind. However, if people could provide example .blends (preferably 2.5) of the BGE exhibiting poor performance (and this performance actually getting in your way), then I would be happy to look at it (when I have time). And please, be sensible: low fps on a scene with 1mil polys and 10 spot lamps is expected and not going to change anytime soon.
Cheers,
Moguri
Ogre supports GLSL, HLSL and Cg shaders, along with a full fledged HDR solution, ready to use. There is support for CEGUI, and a few other user interface libraries, that use freetype wonderfully to render in game fonts. The OGRE scene graph is top-notch, shaped through years of <i>active</i> development.
The greatest benefit: a community of active developers dedicated to real-time graphics.
With OGRE, we would be future ready. 
The greatest benefit: a community of active developers dedicated to real-time graphics.
What, are you saying that Moguri & co are not active? They have advanced the BGE quite a lot!
I do agree with this that they are active, Dfelinto was actively working on creating a new interface for the logic bricks free of the old cruft for a while. Moguri, NexYon, and Nicks are also quite active as part of being in the GSoC program.
You may argue that Ben2610 is not active right now, but the reason there’s no commits from him is because he’s busy mentoring for Nicks’ project.
No, I’m simply making it clear that the OGRE community is consistently active, and that it’s very likely to remain that way; I view that as a “future ready” benefit from our perspective. So, if someone really wants to improve the state of graphics in the BGE, integrating OGRE (no matter how difficult it may be, initially) is the right way to do it.
But again, it’s not a critical issue for me. When someone does some decent Python work, I’ll be impressed, until then, I view most of these “advancements” as little more than mental masturbation, and not just because it’s already been done in OGRE and other libraries:
For the kind of games that you can actually manage, as part of a small team, or as a single independent developer, you’re not going to need hardware tessellation, or some fully integrated nav-mesh generator, or yet another coat of paint over the fundamentally troublesome logic brick framework.
You’ll need a good Python interface, and an intuitive way to define objects, events, and what happens to C when A performs some action on B.
That’s really the kind of stuff that can help you ship something that’s fun to play, rather than just “neat to look at”.
I think that we should stop this thread, there is no point we keep arguing against the other member’s arguments. Everyone here have a point, and looks like that this discussion is leading us nowhere. Its more hurted Ego than empirical evaluation.
Looks like a vicious circle, came on!