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.

Viewport FX II

Jason Wilkins

Email: Jason.A.Wilkins@gmail.com

IRC: jwilkins

http://sites.google.com/site/jasonawilkins


Synopsis

This is a proposal to continue work on updating the way Blender draws to the screen. Blender relies on an older version of the OpenGL graphics library that is no longer fully supported by hardware providers. For this reason, when new generations of graphics cards are released, Blender will not fully benefit from the increases in capability and performance. In addition, new mobile devices show every indication of becoming the primary means by which most people use computers. For that reason, Blender and its game engine should be made to work with OpenGL ES, which was designed for those kinds of systems.

Status

Blender currently relies on OpenGL 2.1 along with various extensions. While legacy OpenGL applications will be around for potentially decades to come, the support they receive from hardware vendors will diminish. Currently this reduction of support has manifested itself as crippled performance when using legacy features as compared to updated applications. Eventually legacy applications will have to rely on parties other than the hardware vendors or be stuck using old hardware.

Notable features that need to be updated are:

  • Immediate mode geometry
  • Selection
  • Anti-aliased lines and points
  • Lines wider than one pixel
  • Lighting
  • Pixel rectangles
  • Previous work in updating these areas, and others, has met with success but is incomplete. This project has been treading water by maintaining its branch against the current production version of Blender. Acceptance of this proposal would provide the best chance of this project getting completed.

Approach

The approach taken in updating Blender is to reduce its dependency on OpenGL to what is referred to as the OpenGL Core set of features. However, the OpenGL Core is rather low level and provides an open ended programmability that is not needed by basic Blender operation. Using such a low-level library directly would be difficult to maintain (and legacy OpenGL has proven difficult enough already). For that reason, after studying how Blender makes use of deprecated features, wrapper library have been designed that implement those features, but uses OpenGL Core. This approach leverages the knowledge that contributors already have of OpenGL while at the same time simplifying the drawing code.

Benefits

In the short term the benefit to Blender should be increased performance for those with modern graphics cards. However, the primary benefit of this project is that Blender will be prepared for a future on faster and more mobile hardware. Additionally, future projects, such as refactoring the viewport, depend on having a solid foundation (this project itself originated from an effort to refactor viewport draw that was stymied by legacy OpenGL code).

Once legacy OpenGL code is separated from the rest of Blender it can eventually be removed which will simplify maintenance.

Emerging technologies such as stereoscopic displays and virtual reality would also be better implemented on top of code that complies with up-to-date specifications.

Risks

Several potential risks have been considered when formulating this proposal. The first is that contributors to Blender who write OpenGL code will have a difficult time adjusting to what might amount to a pseudo-OpenGL and for that reason any API that is implemented will need to be well documented.

Another concern is that changes need to be made to the external dependency of GLEW and unless handled well these changes may not make it back upstream to the original library. To mitigate this risk the changes to GLEW will be maintained on GitHub and in consultation with the maintainers of GLEW.

The next risk is the regression of well tested functionality due to re-implementation using non-deprecated functionality. One way to help with this is the creation of a test suite which includes code coverage tools. Although there is not a means to automate these tests yet, the goal is to visually inspect what is drawn while being sure that all drawing code is being executed in some way.

The final risk that has been considered is that this plan is not bold enough because only abstracting part of OpenGL, and not all of it, into a generic graphics library is only a half-measure. An counter example to this is the ANGLE implementation of OpenGL ES which is implemented on top of Direct3D} (the only other library comparable to OpenGL). Perhaps for this reason, restricting the API to OpenGL ES can be thought of as a good enough abstraction for targeting any hardware.

Schedule

Tasks for this project can be divided into three kinds. The first is work that has been previously completed or nearly completed that needs to be finished and tested. This includes the replacements for immediate mode and matrix transformations, and the on-surface brush for sculpting. The second is work that has only been designed and partially implemented. This includes points, lines, lighting, and modifying GLEW and GHOST. Finally, there is work that has not been attempted yet. That includes fixing selection and a foundation for supporting stereoscopic 3D.

The priority for the first half of the term will be getting work that is close to being completed into a state where it can be integrated into trunk. This should be done by week four. The priority for the next four weeks will be breaking Blender's dependency on deprecated features once and for all by finishing the rest of the abstraction layer. One important regression from removing deprecated features will be that selection will no longer work. This and other more minor features will be the focus of the last four weeks.

Milestones

By midterm Blender should be able to run on either OpenGL Core or OpenGL ES on a desktop computer while using no deprecated functionality. (I do not have the hardware needed to port this to Android). OpenGL ES should be available through either the GLX/WGL/AGL extension or by linking with ANGLE. However, it should be expected that there will be some regressions and missing features at that time. By the final evaluation all of those regressions should be fixed and some additional features as detailed in the next section should be available.

Blender will...

  • ... run when linked with ANGLE
  • ... run when using the core profile.
  • ... gracefully degrade quality or performance when running on legacy OpenGL versions.
  • ... not make any calls to deprecated functions on recent hardware.
  • ... use color buffer selection or ray casting to do selection instead of select mode

Details

This is a, much condensed, version of a to-do list for this project:

  • Create an \emph{OpenGL} state policy that programmers should follow to efficiently change state without intefering with other code.
  • Complete work on the immediate mode replacement library.
  • Simplify Object and Edit mode drawing paths.
  • Complete work on the client side vertex array replacement library.
  • Complete work on replacing display lists that do not contain state changes.
  • Complete work on the matrix transformation replacement library.
  • Complete work on the GLU replacement library.
  • Complete work implementing legacy lighting using shaders.
  • Complete work to add \emph{OpenGL ES} support to \emph{GLEW}
  • Design and implement a non-legacy selection method.
  • Design and implement a point library based on point sprites (or alternative).
  • Design and implement a smooth-thick line library based on shaders and triangles (or alternative).
  • Design and implement a bitmap font library based on signed-distance.
  • Complete work to add the ``on-surface brush for sculpt and paint modes.
  • Write good documentation of how to use the wrappers instead of \emph{OpenGL} directly.

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.