What do you want work on?
I want Ton to work on a foundation film and in same time his associate game, this is only by this way that gameBlender 's going upgrade!!!
Pit
I’m interested in 2 things:
1)adding a built in terrain system, plus vegetation system. This will require adding an automatic LoD and other stuff
2)adding a way to fully manipulate meshes, giving a good api for doing so.
But for this quite complex, and i’ll need to study a lot to add this.
If you meant “what do you want others to work on?”, i definitely choose NODAL LOGIC!!!
I will vote for Nodal Logic!
On the terrain system part, is there enough advantages over simply modeling a terrain that it would be worth the extra code, the advantages of having to model a terrain for example is that it can be completely free-form with overhangs, arches, caves, holes, ect… I know many game engines have terrain systems, but many may lack one or more of the features needed to create something which I listed could be done due to Blender also being the modeling program.
As for the vegetation system, it might be nice if the BGE instead was able to render out particle instancing when a particle system set to visualize the particles as objects and such you could paint them in particle mode, this would mean that you would not only have a system for vegetation, but for any object type for that matter.
I’m waiting on Enja in that respect
I put a thread on TIGForums, as a lot of the people there are programmers, and may be able to help out. I put a URL to this thread in case they want to see what the BGE could use for upgrading. List of wanted features:
Point Light Shadows
Sun Shadows (may be able to do something about that myself; I have to see)
Deferred / Inferred lighting
Faster Python execution
Faster Rendering
That’s all for now. As for your poll, agoose, I would voted for Python execution. It could be faster, and it would be nice if more advanced functions were exposed to Python.
I agree^^
Although, i think we not only want a faster rasterizer, but:
OpenGL 4 support #from opengl 3 upwards faster than current 2.x
Post Processing Bloom and Depth Of field. #integrated into trunk filters
Better shadow support #faster
Soft shadows (Feature freeze in trunk)
I really love the concept of a level editor like UDK, but i would need to think about it.
As soon as i’m free, i’m going to start looking at either rasterizer / level editing concepts, then the source.
Anti-aliasing, anisotropic filtering, the rasterizer, and tesselation.
On the part in bold, it’s already in 2.58 (check the preferences)
Here’s some of my thoughts on some of the suggestions made here:
Point light shadows: This are terribly expensive since you essentially need six spotlamps for the shadows.
Sun shadows: This should be pretty easy to add since sun lamps are similar to spot lamps. However, if the shadows cover a large distance, the shadows further away from the sun lamp will start looking pretty bad. Cascading shadow maps could help here.
Deferred / Inferred lighting: This would be nice. It would take some work, but should be doable. Kupoman has some pretty nice ideas for this.
Faster Python execution: This one is difficult to do from our end. We’ll just have to wait for Python to get faster or for PyPy to support embedding.
Faster Rendering: Kinda vague, but this would be nice too. More specific things like faster shadows would better for a wishlist.
OpenGL 4 support: Why? OpenGL 4 doesn’t really offer us a whole lot that not available in extensions in OpenGL 2. Is there something specific that you wanted?
Post Processing Bloom and Depth Of field: Look around on these forums, you can find custom 2d filters for these. I would like to add some of the more popular custom 2d filters to the BGE, but first I want to work on the 2d filter system a bit.
Better shadow support: I’ve been working on variance shadow maps. They’re about ready and I’ll probably look into finishing them up when the feature freeze is over. This will help with soft shadows. As for shadows on other lamp types, I’ve already listed my opinion on those.
Anti-aliasing: We already have this. Use the -m flag for the Blenderplayer (e.g., for 4x AA use: game.exe -m 4).
Anisotropic filtering: As Ace Dragon mentioned, we have this.
Tessellation: I think we have other things to worry about at the moment then real-time tessellation of objects.
Lightmaps maybe? i know solarlune worked on a “form” of lightmapping.
The main issue are:
threading, particles, procedural textures and rasterizer - it’s old, and we’re starting to feel it.
The main point is that while it is useable now, in a few years, few will feel the advantages of blender integration over superior features
Threading would also increase speed.
I didn’t meant a tool that help do create terrains, but a system that allow open worlds. In every open game the terrain is loaded dynamically. Even if it is already possible to do this with python(dynamic loading), having a fast and suited way to load seamless terrain would be nice (i think).
i read on the maiing listl that blender used only opengl 2, and that using more modern api would help in speed. But maybe this is not true for bge rasterizer
Well I would agree that a system that can load patches dynamically would be nice to have. In many game engines, the patch loading is mainly done with very large terrains, but since Blender doesn’t use any special mesh-based object, you would need to have it so that any static level geometry with a large enough scale can be split to load into patches during runtime (which might even be cube-shaped patches for cases like terrain with buildings), and then any other objects that are in the patch region would be loaded and unloaded into the game with the patch itself.
Now the idea here would be that the splitting could be done automatically via a script that would even generate the .blend files in a folder and link the objects back into the working area, then you would have an option to enable dynamic loading with parameters like distance from the camera and the path to the folder containing the patches, this being done in a separate thread to not disrupt gameplay when a patch is loading.
The thing here is that you’d pretty much have an improved version of the existing functionality available via the UI, the Python API could then be extended to offer specific control like manually loading in and unloading patches that aren’t needed which would overwrite the distance parameter.
Back to generating the patches, I wonder if it would be possible to do just a virtual split that would only be seen by the dynamic loading system so you can still work on a terrain or a structure in editmode as if it was still just one object (which would make it a lot easier to continue editing or tweaking the geometry)
I think more of a splitting at conversion time (all blender meshes are converted in bge meshes when you run the engine). In addition, would be cool to have an automatic LoD function that given the max verts outputs a reduced mesh with that much vertices(i posted a link to such an algorithm in the other thread.)
OT:
maybe we should ask to mods to join the 2 threads in a single one. We are talking of the same thing here and there
yes i guess
Logic bricks features and increase its speed would be what i would be asking for ,i tot in the new version of belnder 2.58 would come with more features but it didnt happen,Mouselook script looks a bit deprecated for me,it works well only for 1st person shooter game not for rpg games…but i still love blender coz it started creating my first game projects with it so im very greatfull for that!but improvements is always welcome! i agree with most of Agoose77 pointed out!
nice poll thread btw!
Romy
PS: Particles system for GE would be also my ultimate wish!
python (improvements)
mhm! definately something to consider!
Someone keep this alive, whilst i’m away for a week!
My wish list:
Integrated ragdolls
Downsampling filters
More control with python - although this has been addressed recently
Differed/inferred lighting - needed badly IMO
Sun shadows - cascaded shadows should work here
Point shadows - even if they are expensive the option should still be there
Anti-aliasing in the viewport
Terrain manager - height maps would be nice with tessellation
Seems like every year my wish list gets shorter as blenders feature list grows larger 
Ex.