Viewport FX III Proposal

Synopsis

This is a proposal to complete previous work on updating Blender's viewport drawing code. Due to previous work, the Viewport FX branch of Blender no longer depends on legacy versions of OpenGL, additionally it can run on mobile systems using OpenGL ES. A large part of what remains to be done are optimization and testing. Optimization will involve finding the worst bottlenecks that diminish drawing performance and mitigating them. Since almost all drawing code in Blender has been modified by previous work, there is a potential for new visual errors to appear from previously working code, so testing has to be done. Both optimization and testing would be enhanced by involving the Blender community. Additionally, a replacement for the deprecated OpenGL selection mode needs to be implemented to accelerate picking objects in the viewport.

Status

The following is a list of features that have been completed or nearly completed. (Note: An "aspect" is my own term for a set of shaders that serve a similar purpose and have similar parameters. You might also call it a "shader class".)

Immediate Mode Replacement for convenient drawing similar to glBegin and glEnd
DrawPixels Replacement for drawing images
GLU Replacement for drawing standard geometric figures
Common Framework for giving "well-known" parameters for programmable clipping, transformation, and lighting
Aspects for controlling classes of programmable shaders
Basic Aspect for solid drawing
Codegen Aspect for drawing Blender materials
Font Aspect for drawing glyphs
Raster Aspect for drawing wireframes and stippled primitives
Sprite Aspect for drawing points

The following is a list of things that remain to be done before this work can be integrated with Blender.

Selection Mode Replacement for 3D picking
Review of code
Porting change to GHOST to Mac OSX and Unix
Optimization of drawing performance
Testing for visual regressions

Approach

The approach taken for optimization will be to request problematic scenes from the Blender community and to also develop original scenes. These files can then be profiled to discover bottlenecks. CPU profiling tools as well as OpenGL profiling tools will be used guide optimization. Preferably, profiling, or at least benchmarking can also be done on on a variety of actual user computers.

The approach taken for visual regression testing will be the development of test files that exercise all of the drawing code in Blender (aka, white box testing). Scripts will help keep track of how much code has been tested. (These scripts have already been written.)

Although a lot of checking for visual fidelity can be done while developing the test files, repeating the tests should be done by instrumenting Blender with the ability to take screenshots automatically and compare them to examples from an unaltered copy of Blender.

About 3D picking, without prototyping various solutions it is difficult to predict which approach should be taken. The original code based on GL_SELECT had the advantage of adding minimal complexity to existing drawing code, but this code can kick modern OpenGL drivers into software rendering mode, so it can be very slow.

Solutions in order of preference: An approach similar to GL_SELECT would be to use a technique based on the color buffer instead of a selection buffer. Another approach would use occlusion queries (such code has already been implemented). Yet another approach would use ray casting similar to how sculpt mode currently does picking.

Benefits

Besides the eventual integration of the benefits of previous work done on the Viewport FX branch, the benefit of the proposed work will be that the Blender viewport should support scenes of complexity closer to the limits of what a user's graphics card can support.

Taking time to ensure that changes have not resulted in visual errors and automating the process provides confidence in the new code and can be used in the future to detect unintended changes or to compare different versions of Blender.

Rewriting the 3D picking code will make Blender more usable with large scenes that get bogged down due to the lack of hardware acceleration.

Risks

Several risks have been considered while formulating this proposal. The first risk considered is that a defect in the design of Viewport FX is discovered and must be fixed before proceeding with the rest of the work. Considering the footprint of the changes in Viewport FX this is definitely possible. However, at this point I am familiar with the work required to make changes that are widespread to existing code and I am confident this would not cause any major delays.

The second risk considered is inherited from the previous year. Viewport FX makes use of a customized version of GLEW in order to support OpenGL ES and these changes have not been made available to the upstream provider yet because they are incomplete. If the maintainers of GLEW eventually reject the custom GLEW-ES then a fork will have to be maintained. However, this fork is only needed when building for OpenGL ES.

Finally, there is a risk that eliminating bottlenecks requires changes that are too difficult to achieve within the time allowed or that after testing the code cannot be made stable enough to allow inclusion in the master branch. To mitigate this potential problem, much of the code of Viewport FX can be marked as experimental and the old code paths have been maintained. This would allow Blender to be built without the problematic code, but still allow inclusion in the main branch.

A note: I see this proposal itself as risky, since while there are many things I could propose to focus on, optimization and testing may be considered inappropriate. If that is the case then I have a long list of items that could be done for Viewport FX already compiled on the Blender wiki.

Schedule

It would be preferable if the code review and porting to OSX and Unix could be done before the Summer of Code period even begins. It would also be good if certain parts of the previous work, such as the changes to GHOST could be integrated by then as well.

Implementation of a new selection mode, most likely based on the color buffer, should take about one week.

The production of and solicitation for low performing test scenes should take about two weeks.

The production of a set of files for covering all drawing code should take about one week, and can overlap with the time taken to produce performance tests.

The elimination of bottlenecks is somewhat open ended due to the fact that one can always attempt optimize more and more. This should start as soon as the bottlenecks are identified and continue until the end of summer.

Finally, allow one or two weeks for documentation and preparation for integration with the master branch.

Milestones

By mid-term ...

... a replacement for GL_SELECT mode shall have been implemented
... the changes to GHOST ported to OSX and Unix
... all currently existing visual regressions shall be fixed
... a suite of low performing files shall be compiled
... performance bottlenecks shall be identified

By finals ...

... the most serious bottlenecks have been reduced or eliminated
... the code is ready to be integrated with the master branch

Bio

I was born in Jonesboro, Arkansas, USA. I've always been a huge computer graphics nerd ever since I started poking around with plotting huge pixels on some of the earliest personal computers as a child. These days I never miss seeing the latest animated film or special FX heavy movie. It is my goal to work in the film or game industry.

I am currently working towards my PhD in computer science at Texas A&M University in College Station. My research currently involves applying advances in programming languages to computer graphics in order to achieve higher productivity and performance. I want to free computer graphics programmers from the cost associated with programming in low level languages.

利用者:Jwilkins/GSoC2014/Viewport FX III Proposal

目次