From BlenderWiki

Jump to: navigation, search
Note: This is an archived version of the Blender Developer Wiki. The current and active wiki is available on wiki.blender.org.

Name

Daniel Stokes

Email / IRC / WWW

My email is kupomail@gmail.com
My IRC nick is kupoman, and I can be found in the following channels: #gameblender, #blender, #blendercoders, #bgecoders
I have a blog that mostly has posts from last 2011's Summer of Code that can be found at kupoman.wordpress.com

Synopsis

While large new features are always exciting and welcomed by the Blender Game Engine community, it is also important that the Game Engine receives some dedicated maintenance. This project does a little of both by implementing a level of detail system and then focusing on bug fixes and small community requested features. The proposed level of detail system is a discrete system that a user can set up using newly added UI in the object panel. The bug fixing and small features portion of this project is meant to be similar to the Cucumber branch from the 2011 Google Summer of Code (video).

Benefits to Blender

This project will benefit Game Engine users by improving software reliability and the user experience. Furthermore, the level of detail system will allow Game Engine artists to make more efficient use of processing resources, and allowing them to create richer content with the Game Engine. Currently users have to write there own level of detail systems, using up valuable development time on their projects.


Deliverables

  • Integrated mesh level of detail support
  • Community requested features (to be determined)
  • 30-50 bugs fixed
  • Documentation of any new features


Project Details

The level of detail system will work off of a base Blender object. The base object is the highest level of detail object. In the object panel of the base object, new UI will be added to specify the objects used for the other levels of detail. Along with options to set the objects used for the levels of detail, there will also be the option to set the distances at which the levels are active. To avoid tediously setting distances on every object, global distance settings will be added to the render panel. Any distances set in the object panel will override the global distance settings. During run time, these settings will be used to automatically swap out objects based on distance. Hopefully some previous calculations (such as those used for view frustum culling) can be used to reduce or avoid the cost of determining the distance to all level of detail objects.
To handle the community requested features, a thread will be started on the Blenderartists forums. While this thread will likely generate a lot of noise, it will hopefully provide some insight into improvements that will help the community. Reasonable ideas will be discussed with my mentor and other Blender Game Engine developers to determine if they are worth working on for this project. Three to four of these ideas will then be selected and implemented.
The Blender Game Engine bug tracker continues to grow (as of this writing there are 201 open bugs). This project specifically aims to tackle a large amount of bugs to improve the stability and usability of the Game Engine. The goal is to identify 30 to 50 bugs (likely chosen on a weekly basis) to investigate and fix.


Project Timeline

  • Integrated mesh level of detail support (3-4 weeks)
  • 3 -4 Community requested features (about 4 weeks)
  • 30-50 bugs fixed (remaining time)
The last day of my academic school year is June 14th, meaning I will be able to jump right into the project after the introductory period. I currently am not planning any large vacations for the summer.

Bio

I am a student studying at Eastern Washington University (located in Cheney, Washington, USA) to earn a Master of Science degree in Computer Science. I have been doing Blender development for a couple of years now, and participated in 2011's Google Summer of Code in which I worked on various bug fixes and minor features for the Blender Game Engine. After completing the Google Summer of Code I began contributing in the Harmony branch in which I did work on implementing shadow support for sun lamps, reworked the shadow panel for BGE users, and added support for changing the shadow's color. These changes have all made their way into Trunk. The current iteration of Harmony I am working is focused on increasing user control over the rendering pipeline as well as adding support for inferred lighting. A considerable amount of this completed and usable, though some features are lacking and stability needs to be improved. I have an understanding of design patterns and principles which allows me to make well thought out changes to the code base.