利用者:Brita/GSoC BGE cleanup and support/reports/final

GSoC14 BGE Cleanup and Support - Final Report

main page | git branch | weekly reports

Bugtracker

I closed 50 reports, including invalid and duplicate reports. This was very time consuming and a major part of my gsoc, as it takes a lot of time testing and interacting with users and other developers. Bugs that would take too much time to fix and/or are a core design issue were moved to a TODO list.

One of my first tasks was to review and categorize the bugtracker, as the old categories were lost in the conversion from the old tracker. I followed up on triagging new tasks.

When both me and Mitchel Stokes were active on the tracker the bug count really went down by ~40bugs, but without active work and so many reports coming in, it just goes up or stays constant at best. Raf Colson is also a great help communicating and testing and simplifying files.

Fixed (Reported) T30173 - 05db026, T35817 - 1ada96f, T33762 - 82313b4, T30630 T40427 - 5640131 cdcd252, T40778 - 0eb272d, T28908 - 2e5bd8d

Fixed (Unreported) 1a1fcba, 06a86b9, bbf6b05 and more

Closed / Archived / Invalid T37909, T36929, T39302, T32059, T18634, T36238, T18182, T18524, T6430, T40544, T18134, T19362, T32771, T28974, T40614, T28888, T40486, T40767, T40704, T39401, T40341, T40114, T38564, T37824, T37762, T36484, T38474, T33564, T40612, T19714, T38320, T40990, T41069, T41030, T41037, T30082, T38030, T41214, T41365, T38320, T34132

UI Review

The goal was to start removing some unsupported options from the properties panel, but this was abandoned after some discussion as some of the proposed removals would require large changes to blender's UI code, namely removing options from menus (Add Constraint and Modifier) and removing tabs. The rest of the proposed changes are removing specific buttons/widgets from inside the panels. I tested-removed one of them, but the conclusion is that this would lead to code clutter and layout alignment problems (f12c182, f80b139). I left notes for future reference and for user reference too.

SceneGraph

SceneGraph UML for the developer documentation

I thoroughly reviewed the GE SceneGraph structure and all related bits, including the initial data conversion. The goal was to close all related bugs on the tracker and prevent new ones, but some are related to core design issues and can not be easily fixed. I spent quite some time with this review, as the scenegraph is a core structure of the GE. cleanup and thorough review. It was a useful learning process for me, and I summed it up on the dev wiki.

• cleanup and review (f12c182, 00d0d96, db6abb6, 2e5bd8d, 1890168, 1ba0afc, bf51d62, 5ba18bc, 51810ed, 88f2b48, 86d8f10, 8468a28, 514c53e, 52d2099)
• related bugs - I closed reported and unreported bugs. I made a design task to parent the ones that can not be easily fixed without a recode.
• SceneGraph Documentation - the documentation has a questions and a problems section. I could not find anyone to advise me on this.

Physics

Developer Documentation - Rigid Body Pipeline

I spent some time learning bullet code and basic physics concepts. Documentation for bullet is hard to find, and this was a time consuming process for me, so I made an effort to make it easier for next developers by documenting my findings.

Documentation

I made a page for Physics Developer Documentation, comprehending basic concepts, bullet overview and wrapper implementation. Some of it is still on paper, I have to copy to digital :)

(Not) Upgrading to Bullet 3.x

Based on a paper by Erwin Coumans: http://www.multithreadingandvfx.org/course_notes/GPU_rigidbody_using_OpenCL.pdf
The paper describes Erwin's latest work to optimize the rigid body pipeline.
In short, he has already refactored and included several optimizations in the bullet 2.x code (which Blender is using).
The 3.x version is not yet complete and is a full re-write to run on OpenCL. It is supposed to be quite fast, capable of simulating 100 thousand rigid bodies in real time. It is a complete re-write because the previous algorithms and data structures did not translate well to parallel computing.
Bullet 3.x follows different philosophies, it is written in C and not C++ and the API is more limited.
All this makes it difficult (and early) to make the jump from 2.x to 3.x as the new bullet design is not compatible with the current GE way of working.

Convex Hull Computer

I looked into the possibility of automatically decomposing a 3D mesh into convex shapes using an existing algorithm. I found that bullet has a recent btConvexHullComputer, but after some discussion this seems too big of a change for the end of gsoc. Sergej Reich has already experimented with it and it had problems at the time (maybe it doesn't now). The algorithm can be heavy depending on the model, so it is probably better to provide an offline, interactive tool to decompose the mesh and use the saved result.

Exposing the Vehicle Controller

( this work is unfinished) Currently there is a wrapper for Bullet's raycast vehicle implementation, but is only accessible via Python. A basic version of this feature would be accessible to more users with an user interface. I discussed the implementation with Mike Pan, and it consists adding 'vehicle' to the Motion logic brick and of adding the setup interface as a 'Physics Type' for an object, where you could set the vehicle specific settings and add wheels.

The implementation however, did not go smoothly, as currently the Vehicle Wrapper is implemented as a Constraint and not as a Controller. Changing this involves quite some work and breaks compatibility with previous scripts and blend files. Keeping the Constraint implementation, either by itself, or in combination with a new controller wrapper, is a less than ideal solution as it is definitely not 'clean'.

Code cleanup

Minor cleanups, formatting, clarifications, removing of unused code, etc. (8060887, 9c95ea3, 16741f0, 5a511eb)

I invested some time in a bge submodules initialization cleanup, following up a bugreport: T40132 (14fceb6, d503f8a, 140a3ac)

Documentation

Developer Documentation

I reviewed all the previous structure and pages of both the Game Engine and Physics Documentation. I added an 'outdated' note to pages out of the scope of my gsoc and completely remade others, such as the Game Engine Overview. Here is the full list:

• Game Engine Overview
• ToDo and Design Issues
• Current Branches and Projects
• SceneGraph Overview
• Physics Overview
• UI Unsupported bits

User Documentation

I checked the user wiki on bge physics (only). It seems to have been all written by a summer of documentation student. It is missing quite some features and outdated. Though some parts are not bad, I dislike the organization, and parts of the text are really unprofessional. I cleaned up these where I saw it, but he did write a lot, so I could not aim to properly restructure/review/rewrite this. I aimed instead to write new, focused and currently missing pages on the specific parts I am working on, such as the vehicle controller.

Review of active projects

I contacted the authors and looked into all branches and projects that were listed on the wiki or mentioned by other developers.

This is the resulting list.

BGE meeting

As part of my gsoc, I organized a developer meeting to discuss priorities and the roadmap of the BGE.
See the summary. There is also a BA thread on the subject.

The meeting was attended by several people and the discussion lasted for quite some time. Most of the attendees are interested users or developers who can not do more than what they are already doing. There is also very little consensus on how best to unblock the game engine from its current status. We decided to continue to discuss the subject more frequently and to also do so in the regular weekly meeting but this did not went forward. Unfortunately there is not enough developer interest and guidance on this area.

For future reference, I highlight here some of the discussed topics:

• integrate the current GE code better (advantage of less bugs and better user experience, disadvantage of being harder and limiting to maintain)
• separate the current GE more as an orphaned project and develop a new 'interactive' system
• make a new GE with a permissive open source license to replace the current GE (most developers agree that it is easier to just start over)
• work on an API similar to the Render API so that game engines can connect to Blender. It was mentioned that Panda3D would be a good candidate for this.
• logic exporting along with the scene setup so it can be run in other GE / browser. See blend4web.
• the physics wrapper is very fractured. It should be rewritten together with blender's for a better physics unification
• logic bricks: this system's design is very outdated and is limiting. A node based system seems to be popular, Angus Hollands is working on HIVE integration.
• performance: there are some bloats with the current code base. Only parts of the animation system and physics are multithreaded.

Follow up

There is a lot of 'future work' to be done in cleaning up and supporting the Game Engine.
I leave here the pointers for things that I I documented proposals for some specific parts that were out of the scope of the gsoc:

• Game Engine TODO list - link
• SceneGraph and Transforms - link, phab task
• GE Math Library - link,phab task
• Slow Parent as a constraint - link
• Redesigning Input Controllers/Sensors - phab task
• Researching how to solve the multiple physics bug reports with a triangle mesh collision shape as origin, I looked into the possibility of automatically decomposing a 3D mesh into convex shapes as mentioned above
• Exposing the Vehicle Controller - mentioned above
• Documentation - Both user and developer documentation are seriously lacking. An idea for non-coders would be to translate the recent french documentation project.

Special thanks to
Sergey Sharybin, Sergej Reich, Campbell Barton, Bastien Montagne, Lukas Tönne, Antony Riakiotakis, Francesco Siddi, Mike Pan and my mentor
for the help and support