利用者:Jwir3/SummerOfCode2007/OpenGL Redesign Proposal

Redesign of Blender OpenGL Code

Scott Johnson
email: scottj@cs.umn.edu
irc nick: jwir3

Synopsis

Blender's current codebase utilizes OpenGL for drawing its user interface and 3D view. Some of the OpenGL function calls use an immediate-mode vertex rendering system, which happens to be slower than newer function calls and technologies available in the OpenGL standard [1,2]. This project seeks to refactor the 3D view window, specifically the object and edit modes, to use more recently standardized methods of drawing in OpenGL. This will in turn generate faster user interface drawing, and thus input response times in large projects.

Benefits to the Blender Community

Through the use of newer OpenGL functionality, the number of state changes made in the Blender code can be minimized [1,2]. This will allow for faster loading of the interface, faster drawing of the graphical menus, windows, screens, and objects in Blender, and most importantly, the ability for slower machines to draw more mesh objects before becoming bogged down. Faster screen drawing times will yield faster response times for user input, helping to eliminate system lag for users. The refactor will also be designed in a clean and clear fashion, ensuring that it can be replicated for additional modes besides the edit and object modes. The final code will be structured and well documented, so that it may be used as a template for other similar projects, taken on by both myself and other developers. Additionally, refactoring the interface system allows for an update in OpenGL function calls to verify that the codebase takes full advantage of the 1.5 OpenGL standard.

Deliverables

The edit and object mode drawing, (the 3D View) will be refactored for optimized OpenGL drawing methods, as described by Steenberg in [1,2]. (By edit and object mode, I meant that modes such as UV Face Select and others will not be updated, unless time permits. The overall goal is to make sure that the code for one or two modes are cleanly implemented and documented, so they can be used as a basis for adapting other modes). Specifically, the code for the main edit mode window, or the 3D view, will be redeveloped, much of which is located in src/drawview.c, however there is OpenGL code scattered over much of the Blender project. All of the edit/object mode code will be refactored to include the optimizations, and as they are refactored, they will be documented (They will be documented both in terms of in-code, as well as external documentation. There will also be documentation constructed showing the overall design considerations, and where the code for certain drawing functionality is located). A clean structure will be formulated while these optimizations are being developed and implemented, in order to help guide additional mode optimizations. The overall structure of the edit/object mode drawing code will be organized, so as to be clearly identified which parts were changed, and why (this is to make sure that the template is clear and complete).

These two sections were chosen due to the length of the project. As time permits, additional code would be re-designed, including additional modes such as UV Face Select, but in order to make sure the project doesn't get out of hand in three months, a definitive limit has been set on what will be accomplished. Since much of the utilization in Blender is done with the object and edit modes, it is clear that any small optimization in this code would likely produce excellent speedups. Once this main path has been paved, it should become easier for other developers, including myself, to reimplement other parts of the drawing.

Functionality Details

The only actual new functionality which will be added to the Blender source will be an update to existing OpenGL function calls that may not have been added to the Blender code originally. Additionally, functionality will be added to make sure that older graphics cards are supported. As Blender currently supports the 1.2 OpenGL standard, almost all of the changes will be backwards compatible with this standard, although they may not make use of some of the optimizations discussed in this proposal. Additionally, as it is possible, calls will be made using the 1.5 standard of OpenGL, including ARB extensions as necessary. The project will not utilize OpenGL extensions which are not ARB approved, unless specifically required by mentors and/or under special cases.

Implementation Details

Currently, in Blender, only the file drawobject.c takes advantage of the glVertexPointer function call, which sends a single model to the screen in one large chunk. The interface for Blender will be sped up by eliminating glBegin and glEnd calls (what I mean by this is not necessarily that the glBegin and glEnd calls will be eliminated, but merely that immediate mode rendering will be eliminated). There are two methods currently used in accomplishing this task: display lists and indexed vertex arrays. Display lists allow a program (in this case, Blender) to signify to OpenGL which function calls should be grouped together, and treated as a single entity [3]. In this situation, OpenGL can improve performance, but there are some disadvantages. Display lists force the application with the assumption that state changes will not happen inside of a display list. Normally this isn't a problem, but sometimes it can create a bottleneck if the application programmer isn't careful. Additionally, there are circumstances where a display list may need to be recreated, which is rather expensive in terms of complexity and space. Indexed vertex arrays are one way of passing data to the GPU as a chunk, in order to speed up rendering. The disadvantage for this approach is that there is no ability to specify which data will not change, wasting processing time on geometry which may not need to be re-rendered [3].

Blender utilizes both vertex arrays and display lists in some segments of the code. However, there is a third option which would give the benefits of both situations without the underlying disadvantages of either: vertex buffer objects (VBOs). Vertex buffer objects allow data to be grouped into chunks similarly with regards to vertex arrays, but also allow dynamic changes [3].

For this project, a combination of all of these methods will be used, following strategies outlined in [1]. Vertex buffers, since they are stored on the graphics card memory, are extremely fast to draw, but somewhat slow to bind [1,2]. Thus, for what are considered slow-changing items, vertex buffer objects will be used, and large chunks of video memory will be allocated for these items immediately. Indexed vertex arrays will be used where vertex buffers aren't applicable. Display lists will also be utilized as much as possible, but advisement from the mentor and other members of the community will be sought in order to make sure they are used effectively, since they can also create large bottlenecks or slowdowns if not used properly.

Development Methodology

The development methodology will use an iterative software engineering based approach. A listing of specific requirements will be created, with the assistance of a mentor, as the first task at the beginning of the project. From these requirements, several sets of functionality will be compiled. They will be implemented one by one, each going through a complete phase of development from design to testing, before moving to the next set. Each set will be tested individually, as well as integrated with the entire system. When all of the sets are completed, system-wide testing will be done, and documentation will be written. Advisement from both the mentor and the community will be requested throughout the process, and regular Sunday meetings will be attended, for feedback on the process.

Project Schedule

It should be noted that this schedule is somewhat rough, and is designed to be modified. The exact schedule will be determined as of Jun 2, and may deviate slightly from this. The overall workflow will not be affected, just subdivisions of this schedule will be added.

  * May 28 - May 29:     Deliberation with mentor (once assigned) to work out specific requirements   
  * May 30 - Jun 2:      Development of iterations/coding schedule
  * Jun 3 - Jul 20:      Implementation of individual iterations
                         Some re-organization of the codebase would take place here, if necessary.
  * Jul 20:              My Birthday - hehe :>
  * Jul 21 - Aug 3:      System-wide testing, multiple platform testing
  * Aug 4 - Aug 14:      Final Debugging/Code Polishing
  * Aug 15 - Aug 19:     Writing of Documentation, Final input from community
  * Aug 20:              Submission to Google

Bio

I am currently attending the University of Minnesota as a PhD student in the Computer Science department. My specialization/research area is in Graphics and Visualization. I have roughly 4 years experience working with Computer Graphics. I have 10+ years of experience working with C/C++ programming, and have a passion for software engineering, especially when it comes to games and other entertainment software. I am an advocate of open source software, because I believe it gives inexperienced software engineers the chance to work with those who have had years of prior experience in design, development, and debugging of code which they would not otherwise have had. In my free time I enjoy playing the violin and practicing martial arts.

References

[1] Steenberg, Eskil. OpenGL Performance Programming. Online: http://www.quelsolaar.com/opengl_performance.txt
[2] Steenberg, Eskil. OpenGL Performance Programming. Blender Conference 2006. Transcript available online: http://video.google.com/videoplay?docid=847205086747563852&hl=en
[3] http://www.spec.org/gpc/opc.static/vbo_whitepaper.html