OpenGL ES2.0 Programming Guide - chapter 1:Introduction to OpenGL ES 2.0
Chapter 1:Introduction to OpenGL ES 2.0
What Is OpenGL ES?
In the desktop world there are two standard 3D APIs** : DirectX and OpenGL.
- DirectX : windows
- OpenGL : windows / linux / unix-like / mac
The device constraints that OpenGL ES addresses are very limited processing capabilities and memory availability, low memory bandwidth, sensitivity to power consumption, and lack of floating-point hardware.
The working group used the following criterias in the definition of the OpenGL ES specification(s):
- The OpenGL API is very large and complex and the goal of theOpenGL ES working group was to create an API suitable for constrained devices.
- Removing redundancy was an important goal, but maintaining compatibility with OpenGL was also important.
- New features were introduced to address specific constraints of hand-held and embedded devices.
- The designers of OpenGL ES aimed to ensure a minimum set of features for image quality.
- The OpenGL ES working group wanted to ensure that any OpenGL ES implementation would meet certain acceptable and agreed-on standards for image quality, correctness, and robustness.
There are three OpenGL ES specifications that have been released by Khronos so far:
- OpenGL ES 1.x （1.0 & 1.1）: implement a fixed function pipeline and are derived from the OpenGL 1.3 and 1.5 specifications, respectively.
- OpenGL ES 2.0 : implement a programmable graphics pipeline and is derived from the OpenGL 2.0 specification.
OpenGL ES 2.0
OpenGL ES 2.0 implements a graphics pipeline with programmable shading and consists of two specifications: the OpenGL ES 2.0 API specification and the OpenGL ES Shading Language Specification (OpenGL ES SL).
Vertex Shader
The vertex shader implements a general purpose programmable method for operating on vertices.
Vertex shaders can be used for traditional vertex-based operations such as transforming the position by a matrix, computing the lighting equation to generate a per-vertex color, and generating or transforming texture coordinates.
Primitive Assembly
In the primitive assembly stage, the shaded vertices are assembled into individual geometric primitives that can be drawn such as a triangle, line, or point-sprite. For each primitive, it must be determined whether the primitive lies within the view frustum.
After clipping, the vertex position is converted to screen coordinates. A culling operation can also be performed that discards primitives based on whether they face forward or backward. After clipping and culling, the primitive is ready to be passed to the next stage of the pipeline, which is the rasterization stage.
Rasterization
Rasterization is the process that converts primitives into a set of two-dimensional fragments, which are processed by the fragment shader. These two-dimensional fragments represent pixels that can be drawn on the screen.
Fragment Shader
The fragment shader, as shown in Figure 1-4, is executed for each generated fragment by the rasterization stage.
The fragment shader can either discard the fragment or generate a color value referred to as gl_FragColor. The color, depth, stencil, and screen coordinate location (x, y) generated by the rasterization stage become inputs to the per-fragment operations stage of the OpenGL ES 2.0 pipeline.
Per-Fragment Operations
After the fragment shader, the next stage is per-fragment operations. A fragment produced by rasterization with (x, y) screen coordinates can only modify the pixel at location (x, y) in the framebuffer.
- Pixel ownership test : This test allows the window system to control which pixels in the framebuffer belong to the current OpenGL ES context
- Scissor test : If the fragment is outside the scissor region, the fragment is discarded.
- Stencil and depth tests : These perform tests on the stencil and depth value of the incoming fragment to determine if the fragment should be rejected or not
- Blending—Blending combines the newly generated fragment color value with the color values stored in the framebuffer at location(x, y)
- Dithering—Dithering can be used to minimize the artifacts that can occur from using limited precision to store color values in the framebuffer.
At the end of the per-fragment stage, either the fragment is rejected or a fragment color, depth, or stencil value is written to the framebuffer at location (x, y). The fragment color, depth, and stencil values are written depending on whether the appropriate write masks are enabled or not.
In addition, OpenGL ES 2.0 also provides an interface to read back the pixels from the framebuffer. Note that only pixels can be read back from the color buffer. The depth and stencil values cannot be read back.
EGL
OpenGL ES commands require a rendering context and a drawing surface.
- The rendering context stores the appropriate OpenGL ES state.
- The drawing surface is the surface to which primitives will be drawn. The drawing surface specifies the types of buffers that are required for rendering such as a color buffer, depth buffer, and stencil buffer. The drawing surface also specifies the bit depths of each of the required buffers.
The OpenGL ES API does not mention how a rendering context is created or how the rendering context gets attached to the native windowing system. EGL is one interface between the Khronos rendering APIs such asOpenGL ES and the native window system. There is no requirement to provide EGL when implementing OpenGL ES. Developers should refer to the platform vendor’s documentation to determine which interface is supported.
Any OpenGL ES application will need to do the following using EGL before any rendering can begin:
- Query the displays that are available on the device and initialize them.
- Create a rendering surface.
- Create a rendering context.
Programming with OpenGL ES 2.0
Libraries and Include Files
| type | include & lib |
|---|---|
| headers | egl & opengles2.0 |
| libs | egl & opengles2.0 |
The header file and library names are platform dependent.
EGL Command Syntax
| commands & types | name convention |
|---|---|
| All EGL commands | egl- |
| EGL data types | EGL- |
OpenGL ES Command Syntax
| commands & types | name convention |
|---|---|
| All OpenGL ES commands | gl- |
| OpenGL ES data types | GL- |
Error Handling
The command that generated the error is ignored and does not affect the OpenGL ES state except for the GL_OUT_OF_MEMORY error.
Flush and Finish
The OpenGL ES 2.0 API inherits the OpenGL client–server model.
client : issue commands
server: process commands
Basic State Management
Figure 1-1 showed the various pipeline stages in OpenGL ES 2.0. Each pipeline stage has state that can be enabled or disabled and appropriate state values that are maintained per context.
This state is initialized with default values when an OpenGL ES context (EGLcontext) is initialized.
要点
- 理解opengl es与egl及native window三者之间的层级关系！