Page 1 of 7 123 ... LastLast
Results 1 to 20 of 121
  1. #1
    Member agoose77's Avatar
    Join Date
    Aug 2010
    Location
    United Kingdom
    Posts
    6,795

    Where is the development?

    I have often snatched an envious glance at the likes of Unity 3D, Ogre, UDK and thought 'why don't we have that in Blender GE?' Unfortunately the answer is plain simple:
    Priority of development
    Let me lay out the main issues that we face:
    • An outdated Rasterizer (codebase ~10 years) which faces extensive bottlenecks
    • Incomplete python intergration into the Game Engine (especially Bullet)
    • Single threaded calculations for Logic, Physics and Rasterizer
    • Little funding for paid development
    • Crippling Shadow calculations (especially the soft shadow patch PCF)
    • Inefficient GLSL Lighting calculation


    Introduction:
    This article attempts to isolate, and thus address the issues that the Blender Game Engine face.
    Blender Game Engine receives very little official attention from the Blender Foundation; the majority of trunk additions refer to user submitted content, from developers such as Dfelinto, Moguri and Kupoman (congratulations to them!).

    Comparison:
    In order to make a fair case, i wish to compare our Game Engine to BlendElf. Samuel Anjam was programming his own Game Engine for his portfolio project, and what he has achieved has been superb. After noting that as a sole developer, for a portfolio showpiece, we still can see the difference that a single developer may have upon any project, albeit his own in such a case as BlendELF

    Hold on, OpenGL 2?
    I had mentioned OpenGL 2 as a disadvantage in the list aforementioned, but it had caused some confusion.
    I was trying to highlight the position in which the engine stands. Whilst OpenGL 2 is not a disadvantage, it is an indicator of progress. The latest specification is OpenGL 4, and there are many waypoints in between that mark. The fact that we are currently contented with OpenGL 2, release 2004, suggests that we have not the need for a more advanced library - that the Game Engine is not able to make use of the more modern shading techniques and optimisations, because it hasn't moved with the times. It is not only a lack of new features that we face, but a lack of updates that keep our beloved engine constantly progressing, and moving forward to compare with other engines on the market.

    Why users are 'jumping ship':
    Following on from this, i shall note the lack of AAA Blender games; it's not that we have no skilled users, it's simply that people are realising their limitations, and moving to different engines. It seems somewhat idealistic to hope for a comparison between commercial engines and Blender Game Engine- an open source game engine, for that would be foolish, but there is a link between development and user base. When a developer receives feedback on what features the user base is most in need of, he will attempt to complete the task, in the knowledge that it both satisfies the existing users, but attracts others. With the BGE, it has taken the attitude of a side project - marooned amongst the mass of render enthusiasts. For this reason, it moves at a relatively slower pace to that of it's counterparts. This does not attract users, or moreover, it leaves the community with a high proportion of beginners who start with basic, incomplete projects, then jump ship.

    Why the BGE is an asset to be preserved:
    The Game Engine is an attribute. The BGE attracted me to Blender in 2.4, when i despised the unintuitive interface, i persevered in order to make use of the free game engine. Along my journey to 2.6, i picked up many of the benefits of the modelling environment, this is what probably kept me with BGE. In that time, the biggest change i encountered was an updated Python 3 API, whilst for the modelling environment, cycles has already been implemented into the renderer options. Anyone with a decent idea of cause and effect can see that the BGE would not be an asset to lose, and is in desperate need of attention

    Suggested Course of action:

    Complete the Poll!

    Although i don't expect that by request development would move solely to the GE, i would like to take this oppertunity to sample the community in order see what they want. I ask the community to suggest improvements / modifications for engine-specific features, rather than scripts / content such as mouselook.

    Please complete the poll with the area that you most believe requires development that would aid you best, and after a certain period of time, i shall submit it to the Blender Foundation. After this point, i will be asking for your help in conjunction with the response i receive, in solving these issues.
    Whether we have to employ an independant developer, or call upon our own (Dfelinto, Moguri, Kupoman) we should not sit back and watch our community fall as Blender's Game Engine fades into the sea of free, powerful Game Engines, and ever growing market.

    Features that have been considered/implemented:
    • Nodal Logic - This has been proposed and worked upon, but is limited by the candidates funding
    • Recast and Detour - The BGE finally has an optimised (C++) pathfinding resource
    • Python animation handle - Moguri
    • 3D audio
    • Components* -Moguri

    * denotes incomplete

    Many thanks, agoose77
    Last edited by agoose77; 31-Jan-12 at 13:31.



  2. #2
    Member JohnnyBlack's Avatar
    Join Date
    Nov 2009
    Location
    Earth>Romania
    Posts
    1,781
    BlendELF is just awesome, Blender GE not.
    Making a game with blender is a hard challenge, i will wait , maybe this guy will finish the BlendELF GE. I will leave Blender GE with no resentments once is done.



  3. #3
    Member torakunsama's Avatar
    Join Date
    Dec 2007
    Location
    Luanda
    Posts
    1,821
    Hmm... where to start? 1. Physics + logics: Add a few thousands physical objects with logic and the engine dies. There's an old game I like it's Dark Reign II, although the graphics are very basic, it has reflection, and dynamic LOD (I think), each player (up to 8) can have 1500 units maximum. The game runs smoothly. Its an 11 years old game! 2. Rasterizer + Scenegraph (it seems there's a limit of 10 000 objects that the scenegraph can handle, and a number of polies the Rasterizer can render. The numbers are quite high, but we can't be free to add for instance, millions of particles, by accident (10000 objects adding 10 particles each). OK I undrestand that there must be a limit to everything. 3. 32bit foalt calculi. In 2.49, one couldn't place an object beyond 10 000 units and with clipping scale up to 100 000 BU, now we can go beyond 1 000 000! That is great, only at that distance, the object's position is badly calculated, so the objects do the DBZ style skip... Can we safely use the physics limitations? If I print an object position, I see a + than 8 digits float, so why can't the object have that precision in real-time rendering? 4. Dynamic LOD, it has been asked many times for a long time, it's the second thing most game engine programmers think of when writing one... 5. Materials and texture animation. It's important that sometimes an object changes materials. For example, if an object is dirty or get's wet, or rusty, or changes somehow. An easy way to change/swap materials/textures, would be cool! I'll stop there for now!
    TOMAFORMA
    - Make it Real -



  4. #4
    Member C.A.ligári's Avatar
    Join Date
    Jul 2011
    Location
    Posts
    1,506
    DYNAMIC MODIFIERS
    If Blender itself can handle Modifiers dynamically, the GE also should be able to. It wouldn't be all that useless, just think of some simple Modifiers like the Array. When you align the Array to an Object Offset and change the position of that particular Object, the whole Array changes its form, so you can produce really fancy Fractals (we all love Fractals, don't we?). But within GE that doesn't work, since Modifiers remain static within GE. (I had I great lil' gameplay idea but couldn't realize it so far -- must find a workaround...)
    Or think of the Build Modifier, would be great for some Appearing/Disappearing Effects.

    SHADOWS
    Shadows for Point Lights would be great -- you can not always use a Spotlight to imitate a Point Light; if the Angle is too wide, the shadows won't show anymore. (At least so it seems to me.)

    PROCEDURAL TEXTURES
    And of Course, that would be nice as well.



  5. #5



  6. #6
    Member JohnnyBlack's Avatar
    Join Date
    Nov 2009
    Location
    Earth>Romania
    Posts
    1,781
    I dont want to start writting, because i will have to spend 1 h to write. BUT here is what i think it would be important:
    1. Shadows optimization!
    2.Level editor workflow. (library,assets,prefabs etc.)
    3.2D Filters optimization and implementation.
    4.Faster PY.
    5.ALOT MORE!



  7. #7
    Member Karakasimov's Avatar
    Join Date
    Jun 2010
    Location
    India
    Posts
    1,156
    Threading Ofcouse and Auto Dynamic LOD if possible. This would improve performance upto 3x

    Anyone thinking that we can hire more people via donations or something?
    BGZ - Blog



  8. #8
    Member pit73's Avatar
    Join Date
    Jul 2009
    Location
    Montpellier
    Posts
    28
    Gameblender is hidden ! there is no priority, i'm lazy to observe that! Every body want blender growup, but the gameblender don't move.
    Lots of possibility in the game engine ... i don't understand why community and developpement are not focalised on gameengine developpement. Since the last official fundation game >> nothing more significant.
    A+ Pit



  9. #9
    Member LaH's Avatar
    Join Date
    Mar 2011
    Location
    Sandviken, Sweden
    Posts
    999
    I think we need some 'power' game projects including C++ programmers in the crew hacking on the bge for the games need. These hacks need to be gpl and sources distributed if the game is distributed. That way other can reuse them and the deal with a 'custom' bge build get even sweeter.

    It probably takes some generalization work - but finally the most useful hacks will end up in trunc and accelerate the development of the bge itself.

    It is game developer who have the itch - that where the open source power come from.



  10. #10
    Member agoose77's Avatar
    Join Date
    Aug 2010
    Location
    United Kingdom
    Posts
    6,795
    Here is an email i received from Ton in Janurary. I hope he doesn't mind if i share it.
    Hi Goose,

    I know the GE has a big following and a great potential... but for projects here I also try to follow the daily practice and biggest needs. Already since we're open source, the amount of developers working there is very low, which makes it a tough topic to organize ambitious projects for. It is also hard to attract good artists for a game project; if you're good at game design/modeling/animation, you can get plenty of jobs. For making independent short film the amount of jobs are rare though, so we can pick from a lot of good artists who submit.

    I also have to work with public funding for projects; and both via community channels (dvd pre-sales) as for public funding and commercial sponsorship, film/animation work gets much easier coverage. The games industry does very well here too, commercial work is easy to get.

    Last but not least; making a short film is really a much more coherent and simple/fun project to organize than a 'short' game. Making games resembles a lot to code work, it's a development project, with not much freedom for the artists/developers and a tight very traditional project organization. This is much better off for a (commercial) studio to do, than for a loose bunch of semi-volunteers here

    -Ton-



  11. #11
    Member agoose77's Avatar
    Join Date
    Aug 2010
    Location
    United Kingdom
    Posts
    6,795
    OHHH we could do a kickstarter!



  12. #12
    Mmmm, i think many of the answer are not on the practical side.

    1)Modifiers have to be update to change, this requires time. There is not time to update a modifier within the 17ms the GE has to output a frame. And they aren't so needed.

    2)No modern engine use automatic LOD. This is just a legend that they use it. Why? Because automatic LoD means doing heavy calculation on each mesh. There are systems that automatically create 3-4-n level of detail for a given mesh, but at runtime there is only mesh switch (already doable in blender). Only terrain LOD is done, but this a really specific kind of LOD. *see note at the end

    3)All the rasterizer should be rewrote with newer graphic cards in mind. Modern engines are 1-2-3-4 years old, bge rasterizer is 10 years old. A good volunteer should quite rewrite it all, or at least add some modern method. I think that it uses only openGL 2 calls, we are at openGL 4.1. But this is an enormous task, and a whole GSoC wont be enough.

    4)Just need to better integrate bullet. Bullet is a great physics engine, many games and movies use it.

    5)Logic, physics and rendering in different threads

    Lucky we have GSoC that bring new life into the bge, but it has an old design, and a full rewrite wouldn't be bad, but it is such a great and difficult work that it is reasonable to forgot it, the only hope is a new blender game project, but i don't really think it will be done, since blender is starting to be used a lot in production, and so the blender foundation can't stop to improve blender, or it will lose the professional part of the users.

    Btw you are unfair to the actual bge developers. They are doing a great job. I agree that a lot of improvement is needed, but what already has been done is not a small thing.


    *final note:
    BGE is open source, so WE have to code for it, and not only complain.
    Here a bit of resources to start adding something if you are interested in it

    2)Terrain LoD
    http://number-none.com/product/index.html (Many other resources here)
    http://number-none.com/product/Rende...ast/index.html

    Automatic LoD. Old technology (1997/8), but it is quite an easy algorithm and shouldn't be hard to implement.
    http://citeseerx.ist.psu.edu/viewdoc...=rep1&type=pdf
    http://mgarland.org/files/papers/quadric2.pdf

    3)Deferred/inferred lighting may be cool. It is modern, and a lot of examples have been wrote.
    http://diaryofagraphicsprogrammer.bl...-inferred.html (overview)
    http://graphics.cs.uiuc.edu/~kircher...ting_paper.pdf (Official paper)
    http://mynameismjp.wordpress.com/201...red-rendering/
    http://tower22.blogspot.com/2010/11/...-part-uno.html



  13. #13
    Member agoose77's Avatar
    Join Date
    Aug 2010
    Location
    United Kingdom
    Posts
    6,795
    As usual, i haven't elaborated enough. What i am trying to say, is that whilst we DO have developers working on the GE, the main center of attention is the modelling/ renderer environment. Now, i for one am not going to sit and complain - i'm already jumping into the deep end with the source code. The problem is that it is, like you said, a big task, and thus i think, unless we have another game project, will have to be sorted by an external developer. Now, we have particles, see ENJA, and SolarLune, and there are a few other vitally useful addons, although because of the trunk freeze, aren't currently implemented - soft shadows, components, bgui, your terrain loading, but the fundamental issues like an OLD, SLOW rasterizer are holding us back. The main reason LOD was even proposed ( i expect) was because for our community, it is the only way to speed up our slow games.

    For this reason, i would like some help!
    I wonder if it would be possible to run a kickstarter, then (if successful) employ an external developer to start diggin'!
    I would also like to say that, intergrating a GE so efficiently into the Blender program outstands me, and i do not understimate the time, and effort that has been put into this game engine. It's we're sitting on a time-bomb; eventually we will be left behind by the likes of OGRE, Unity, "gamekit", Blendelf etc..



  14. #14
    Member jplur's Avatar
    Join Date
    Apr 2007
    Location
    Brooklyn baby!
    Posts
    655
    1. Networking. I don't think this should be a built in feature, when python makes it easy to implement.

    2. Threading. What exactly would be threaded? You can use threads already for your own cpu intensive functions. If your bge api calls are taking too much time then probably you are doing something wrong.

    3.Terrain LOD. This can be implemented with the current api: http://www.pasteall.org/pic/15730 Although it would be nice if this was a special object type for both blender and BGE. Foliage (like in Unity) usually uses bitmap impostering which would also be cool but would have to be pretty well developed to get integrated into trunk. (Still I could see lots of use for these two features for production, anytime you need expansive landscape shots.)

    2.Level editor workflow. (library,assets,prefabs etc.) There is a proposal thread with improvements to blenders Groups in the BGE, other than that blender is an excellent 'level editor' as is.

    Btw you are unfair to the actual bge developers. They are doing a great job. I agree that a lot of improvement is needed, but what already has been done is not a small thing.
    +1

    I think kickstarter is a great idea, but maybe focus on hiring someone to work with lower level optimization for the rasterizer and things like deferred lighting



  15. #15
    Member agoose77's Avatar
    Join Date
    Aug 2010
    Location
    United Kingdom
    Posts
    6,795
    Yes, i would agree. I threw networking in there, partially as a joke (It would put me out of business ) Threading is referring to rasterizing on a different thread to logic - otherwise you get hogging of allocated resources by one function



  16. #16
    Member Ace Dragon's Avatar
    Join Date
    Feb 2006
    Location
    Wichita Kansas (USA)
    Posts
    27,332
    Originally Posted by jplur View Post
    I think kickstarter is a great idea, but maybe focus on hiring someone to work with lower level optimization for the rasterizer and things like deferred lighting
    Kupoman actually had a GSoC proposal where he proposed to implement the superior inferred lighting algorithm (slightly slower than deferred but has better support for various shading effects like transparency), but instead decided on another project to fix bugs, polish, and add smaller features citing that the original proposal would be too risky for that timeframe.

    As for a level editor and asset library and the like, the proposal thread for that actually did contain patches that greatly increases the functionality for use of object groups in the BGE, but like all major new features, they have to wait until the feature freeze is lifted (which will be in less than a few weeks if 2.59 ends up being the final, wrap-up release for the 2.5 project.). As for adding functionality like prefabs and a dedicated terrain system, I don't think they are needed because Blender is also the modeling program, you can just model your prefab objects and your terrain without Blender needing special code to handle these. (and modeling your terrain also offers advantages over many dedicated terrain systems in other GE's, for example I heard that Unity's terrain currently doesn't have functionality for holes while you can just delete faces in the BGE)

    As for development priorities being on the main Blender areas of rendering and animation, thanks to Benoit's work and the Yo Frankie! project, the BGE has enough developers to not only keep it maintained, but develop it further with each release, this isn't like the pre 2.46 days where most of what the BGE acquired per-release was more bugs, memory leaks, and slowdowns.

    If one of the sources for these complaints is that you have to select Blender Game from the top menu, the idea was not to hide the BGE functionality, but simply change the UI to only show what's available in the BGE without mixing them with options for the Internal Renderer, it's the same thing with addons where Blender interfaces with other external engines.
    Sweet Dragon dreams, lovely Dragon kisses, gorgeous Dragon hugs. How sweet would life be to romp with Dragons, teasing you with their fire and you being in their games, perhaps they can even turn you into one as well.
    Adventures in Cycles; My official sketchbook



  17. #17
    BlendELF hasn't seen updates in over half a year. The developer may not be able to work on it anymore - at least, not with the current amount of time he has. In addition, while it looks advanced graphically, I'm not sure of how far along it is in actual game design (capabilities, like animation playing, bullet physics, etc).

    I would personally think that getting developers to work on the BGE is a great idea. I'm downloading the source from SVN to poke around and see what I can do, as well, though I haven't used C++ in quite some time.

    It is worth noting that the BGE has been worked on, especially by people like Moguri and Kupoman, who both have put in quite a lot of time and effort into the BGE (and which has already been pointed out). If you didn't notice, Kupoman's builds allow you to run a game as a standalone executable while in Blender, which makes it enormously easy to figure out how your game is going to look and turn out. It's genius. I'm sure there are other features and fixes, but I haven't played around with it much.



  18. #18
    Member agoose77's Avatar
    Join Date
    Aug 2010
    Location
    United Kingdom
    Posts
    6,795
    Thanks SolarLune, i hadn't realised Kupoman had created such builds!
    I too am 'poking around' and i was contemplating building a 'super blender', containing all the valuable & compatible features that are yet to see the trunk because of the 'freeze'.
    What i need now is some idea of the timescale involved, and how much money one would need to employ external developers, or pay past bge developers. I wonder where Moguri stands with this.



  19. #19
    Member Karakasimov's Avatar
    Join Date
    Jun 2010
    Location
    India
    Posts
    1,156
    oh yeah lets not forget the dev's that are currently working on BGE. with all respect they have surely done an excellent job by doing so.

    @SolarLune so true. i think Blendelf is a dead already.
    Me too is learning C (officially) these days as a part of studies.
    i have already done some poking around through blender source code, but had some high priority projects to work on. so wasnt acctually go any further coz of tight schedule. But thats is not the case with a hired dev.

    belive me most people on other so called unty game forums are using Blender for most of their works.
    i think such demand is pushing blender devolopment more to Modeling & Animation part in reality.
    Many even use blender to mod their favourite commercial game.
    it is just not fair [outsourcing].

    +1 to kickstarter
    BGZ - Blog



  20. #20
    Member agoose77's Avatar
    Join Date
    Aug 2010
    Location
    United Kingdom
    Posts
    6,795
    Right, this kickstarter idea sounds promising.
    Any developers who have an insight into funding, costs, time period involved, or even willing to do something, leave some notice on this thread?
    I've also requested my article on BlenderNation.com
    Last edited by agoose77; 01-Aug-11 at 11:09.



Page 1 of 7 123 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •