User:Moguri/GSoC2012 BGE Converter Improvements

From BlenderWiki

Name

Mitchell Stokes

Email / IRC / WWW

I can be contacted via email at mogurijin@gmail.com, and I’m also registered on blenderartists.org as Moguri. Furthermore, on freenode I frequent the #blendercoders, #gameblender, #bgecoders, and #blender channels using the nick Moguri.

Synopsis

One of the slower parts of the BGE is the converter. The converter can take a while to load heavier scenes and is completely blocking until it finishes. This means that scenes can take a while to load, and nothing can be done while the scene is loading. This makes the game look like it "freezes" when loading larger scenes. My plan is to save time by saving converted BGE data out to disk so the data can simply be loaded and used as opposed to loaded, converted, and then used. Also, I would like to make the loading process asynchronous to allow other tasks to be done while waiting for a scene to load.

Benefits to Blender

The benefit to the BGE would be faster and smoother loading of assets. Assets can be loaded while other things are happening in the game (like, displaying an animated loading screen). As a side benefit, the saved conversion data won't be directly usable by Blender, which offers users a little bit of extra security.

Deliverables

• Save out pre-converted files
• Asynchronously load files (blend or pre-converted)
• Converter-time optimizations

Project Details

Saving all of the BGE structures to a file would be a rather daunting task, so instead I will modify the conversion pipeline to go from Blender data to an intermediate and then to BGE data. The plan is to keep the intermediate data structures very similar to the BGE structures to avoid too many further conversion tasks. Ideally, the data in the intermediate structures could be mostly copied into BGE structures. The intermediate structures can then be saved out to disk. Using the intermediate data structures simplifies the saving process since we can limit the number of intermediate structures. To also facilitate in saving and loading the intermediate data to and from disk, I will look into using ReadBlend, bParse, FBTables or possibly Blender's built-in tools (we'll see how nice these play with non-Blender data).

The other side of making file conversions smoother is to allow them to be done asynchronously. To facilitate this I plan to add two new functions to bge.logic: LibLoadAsync() and LibNewAsync(). This will behave similar to their blocking counterparts, but will return some form of future object and do the conversion in a new thread, which will let the game continue to do things while the libraries are being loaded. The Game Actuator (when set to "Start Game From File") will have an "Asynchronous" options (or some similar "user-friendly" wording) that will switch scenes after the new scene has been converted, and not block the game in the meantime.

By saving out files with converted data, we open up the possibility to do optimizations at conversion-time that might normally be too slow to do during run-time. For example, a user could specify to have all of their textures compressed using DDS/DXT to help save on VRAM. You wouldn't want to do this every time you wanted to load the Blendfile in the BGE, but it could be a useful option for publishing. As such, the user would be able to specify when to do this optimizations, which allows the user to turn off the optimizations for faster iterations while developing their game. Other possibilities include baking animation fcurves. I don't know if this would save much time at run-time, but it would eliminate some Bezier calculations. More testing will need to be done to figure out what optimizations would be useful.

Ultimately, the conversion process should not get any slower if the user just wants to use the system in a way similarly to how it is used now. This will make sure that iteration times remain low. Mostly the converter data should only be saved out to disk when publishing a game.

Project Schedule

The project will be split up roughly as follows:

• Add intermediate step to the conversion process -- 2~3 weeks
• Save intermediate data out to disk -- 1~2 week
• Asynchronous loading -- 3~4 weeks
• Conversion-time optimizations -- 1~3 weeks
• Bug fixing, cleaning and docs -- 1~2 weeks

Total time: 8~14 weeks

Bio

I am a 20 year old Computer Science student at Eastern Washington University in Washington state, USA. I have been active in the Blender community for a while now and active as a developer for 2~3 years.

My main area of focus is the Blender Game Engine where I have contributed bug fixes to areas such as lighting, dynamic loading, and the Python API. One of my fist larger BGE dev projects was helping with the new BGE Python API for Blender 2.49. I have participated twice in Google Summer of Code for Blender with this proposal in 2010, and this one in 2011. Both projects were considered a success, but only the second one has made it into trunk.

As far as programming languages go, I know Python and C/C++ fairly well now. I wouldn't call myself a "guru" at either, but I know my way around both languages. I also know Java, but that won't be very useful for this project.