Dev:2.8/Source/OpenGL/Transformations

OpenGL Refactoring: Transformations

Overview

Modelview, projection and texture matrices and the matrix stacks are deprecated, and should be passed as generic uniforms to shaders.

We can implement some APIs to emulate the deprecated functionality, and make those work for GLSL shaders. But it would be good to also consider how we can make this system work without a global state.

We should try to get rid of global state as much as possible when refactoring the code. Such global variables are bad programming practice in general, making it harder to understand the code due to hidden effects, and the same is true for OpenGL drawing.

Global state also prevents multithreading. If the code becomes completely stateless then eventually it might be possible to multithread the drawing code, and have e.g. different threads draw different editors.

Design

Matrix Storage

OpenGL's traditional matrices are full 4x4 stacked up to an implementation-defined depth. For the often-used MODELVIEW matrix the stack depth is at least 32; the others might be as shallow as 2. We are not bound to these constraints when designing a replacement system. We could provide an unlimited stack depth that never overflows, or not use a stack mechanism at all -- though for MODELVIEW the stack has served us well. The other matrix types such as PROJECTION might not need a stack at all.

For common 3D model/view transformations (translate, rotate, scale, mirror) a 3x4 matrix is enough.

For 2D transformations a 2x3 matrix might be all we need. Keep in mind we do lots of 2D drawing in the UI.

The only dimensionalities we care about for drawing are 2D and 3D.

Just like the traditional matrix stack, the shader only sees the single matrix currently on top of the stack.

Matrix Math

No more glTranslate/Rotate/Scale. Also no more built-in functions for perspective or orthographic projection. We must do all this ourselves.

Luckily Blender's math library already handles many of these functions! See BLI_math_matrix, BLI_math_rotation, etc. More functions can be added as needed.

Basic operations needed:

• 2D
  • uniform scale
  • xy translation
  • 90° rotations
  • general rotations?
• 3D
  • uniform scale
  • non-uniform scale (separate xyz factors)
  • xyz translation
  • general rotations (axis-angle)

We should focus on the most common operations. The shader is free to do any further exotic transforms which frees us from having to support every possibility in the client-side matrix stack.