OpenGL ES

OpenGL ES 2.0

OpenGL ES 2.0 was publicly released in March 2007.It is based roughly on OpenGL 2.0, but it eliminates most of the fixed-function rendering pipeline in favor of a programmable one in a move similar to transition from OpenGL 3.0 to 3.1.Control flow in shaders is generally limited to forward branching and to loops where the maximum number of iterations can easily be determined at compile time.Almost all rendering features of the transform and lighting stage, such as the specification of materials and light parameters formerly specified by the fixed-function API, are replaced by shaders written by the graphics programmer. As a result, OpenGL ES 2.0 is notbackward compatible with OpenGL ES 1.1. Some incompatibilities between the desktop version of OpenGL and OpenGL ES 2.0 persisted until OpenGL 4.1, which added theGL_ARB_ES2_compatibility extension.

Supported by:


使用 OpenGL ES 2.0 API 创建图像
创建一个activity设置view为GLSurfaceView同时用GLSurfaceView.Renderer(renderer 是独立于主线程之外的新的线程)控制绘制的内容
package com.example.android.apis.graphics;

import android.app.Activity;
import android.content.Context;
import android.opengl.GLSurfaceView;
import android.os.Bundle;

public class HelloOpenGLES20 extends Activity {
  
    private GLSurfaceView mGLView;
  
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        
        // Create a GLSurfaceView instance and set it
        // as the ContentView for this Activity
        mGLView = new HelloOpenGLES20SurfaceView(this);
        setContentView(mGLView);
    }
    
    @Override
    protected void onPause() {
        super.onPause();
        // The following call pauses the rendering thread.
        // If your OpenGL application is memory intensive,
        // you should consider de-allocating objects that
        // consume significant memory here.
        mGLView.onPause();
    }
    
    @Override
    protected void onResume() {
        super.onResume();
        // The following call resumes a paused rendering thread.
        // If you de-allocated graphic objects for onPause()
        // this is a good place to re-allocate them.
        mGLView.onResume();
    }
}
  
class HelloOpenGLES20SurfaceView extends GLSurfaceView {

    public HelloOpenGLES20SurfaceView(Context context){
        super(context);
        
        // Create an OpenGL ES 2.0 context.
        setEGLContextClientVersion(2);
        // Set the Renderer for drawing on the GLSurfaceView
        setRenderer(new HelloOpenGLES20Renderer());
    }
}
public class HelloOpenGLES20Renderer implements GLSurfaceView.Renderer {
     	    //初始化View的时候调用
    public void onSurfaceCreated(GL10 unused, EGLConfig config) {
    
        // Set the background frame color
        GLES20.glClearColor(0.5f, 0.5f, 0.5f, 1.0f);
    }
    
    public void onDrawFrame(GL10 unused) {
    
        // Redraw background color
        GLES20.glClear(GLES20.GL_COLOR_BUFFER_BIT | GLES20.GL_DEPTH_BUFFER_BIT);
    }
    //屏幕旋转的时候调用
    public void onSurfaceChanged(GL10 unused, int width, int height) {
        GLES20.glViewport(0, 0, width, height);
    }
  
}
绘制一个形状

Mapping Coordinates for Drawn Objects


One of the basic problems in displaying graphics on Android devices is that their screens can vary in size and shape. OpenGL assumes a square, uniform coordinate system and, by default, happily draws those coordinates onto your typically non-square screen as if it is perfectly square.

Figure 1. Default OpenGL coordinate system (left) mapped to a typical Android device screen (right).

The illustration above shows the uniform coordinate system assumed for an OpenGL frame on the left, and how these coordinates actually map to a typical device screen in landscape orientation on the right. To solve this problem, you can apply OpenGL projection modes and camera views to transform coordinates so your graphic objects have the correct proportions on any display.

In order to apply projection and camera views, you create a projection matrix and a camera view matrix and apply them to the OpenGL rendering pipeline. The projection matrix recalculates the coordinates of your graphics so that they map correctly to Android device screens. The camera view matrix creates a transformation that renders objects from a specific eye position.

1.手机的坐标空间


我们都知道要想在手机上随心所欲的绘制图形,就必须了解手机的坐标体系。下图就是将坐标映射到手机屏幕的坐标。

 图1手机屏幕基本坐标系


2.OpenGL基本图形


在OpenGL里,只能绘制点,直线以及三角形。


三角形是最基本的图形,因为它的结构如此稳定,它随处可见,比如桥梁的结构化构件,它有三条边用来连接它的三个顶点,如果我们拿掉其中一个顶点,剩下的就是一条直线,如果我们再拿掉一个点,就只剩下一个点了。


点和直线可以用于某些效果,但是只有三角形才能用来构造拥有复杂的对象和纹理的场景。在OpenGL里,我们把单独的点放在一个组里构建出三角形,再告诉OpenGL如何连接这些点。我们想要构建的所有东西都要用点,直线和三角形定义,如果想构建更复杂的图形,例如拱形,那我们就需要用足够的点拟合这样的曲线。


3.使数据可以被OpenGL存取


当我们在模拟器或者设备上编译和运行Java代码的时候,它并不是直接运行在硬件上的,相反,它运行在一个特殊的环境上,即Dalvik虚拟机。运行在虚拟机上的代码不能直接访问本地环境,除非通过特定的API。


Dalvik虚拟机还使用了垃圾回收机制。这意味着,当虚拟机检测到一个变量,对象或者其他内存片段不在被使用时,就会这些内存释放掉以备重用,它也能腾挪内存以提高空间使用效率。


本地环境并不是这样工作的,它不期望内存块会被移来移去或者被自动释放。


Android之所以这样设计,是因为开发者在开发程序的时候不必关心特定的CPU或者机器架构,也不必关心底层的内存管理。这通常都能工作得很好,除非要与本地系统交互,必须OpenGL。OpenGL作为本地系统库直接运行在硬件上,没有虚拟机,也没有垃圾回收或内存压缩。


Dalvik方案是Android主要特点之一,但是,如果代码运行在虚拟机内部,那它怎么与OpenGL通信呢?有两种技术,第一种技术是使用Java本地接口JNI,这个技术已经由Android软件开发部提供,当调用android.opengl.GLES20包里方法时,软件开发包实际上就是在后台使用JNI调用本地系统库。


第二种技术就是改变内存分配的方式,Java有一个特殊的类集合,它们可以分配本地内存块,并且把Java数据复制到本地内存。本地内存可以被本地环境存取,而不受垃圾回收器的管理。


   图2 从Dalvik到OpenGL传输数据


示例:

private float[] rectangle={

-0.5f,-0.5f,

0.5f,0.5f,

-0.5f,0.5f,


-0.5f,-0.5f,

0.5f,-0.5f,

0.5f,0.5f

private static final int BYTES_PER_FLOAT=4;

private final FloatBuffer vertexData;

vertexData=ByteBuffer

.allocateDirect(rectangle.length*BYTES_PER_FLOAT)

.order(ByteOrder.nativeOrder())

.asFloatBuffer();

vertexData.put(rectangle);


这里加入一个整型常量和一个FloatBuffer类型变量,一个java的浮点数有32位精度,而一个字节只有8位精度,这点可能看起来很明显,每个浮点数都占4个字节,而FloatBuffer用来在本地内存存储数据。


首先,我们使用ByteBuffer.allocateDirect()分配了一块本地内存,这块内存不会被垃圾回收器管理。这个方法需要知道要分配多少个字节的内存块,因为顶点都存储在一个浮点数组里,并且每个浮点数有4个字节,所以这块内存的大小应该是rectangle.length*BYTES_PER_FLOAT。


下一行告诉字节缓冲区按照本地字节序组织它的内容。本地字节序是指,当一个值占用多个字节时,比如32位整数,字节按照从最重要位到最不重要位或者相反顺序排列。可以认为这与从左到右或者从右到左写一个数类似。知道这个排序并不重要,重要的是作为一个平台要使用相同的排序,调用order(ByteOrder.nativeOrder())可以保证这一点。


最后,我们不愿意直接操作单独的字节,而是希望使用浮点数,因此,调用asFloatBuffer()得到一个可以反映底层字节的FloatBuffer类实例。然后就可以调用vertexData.put(rectangle)把数据从Dalvik的内存复制到本地内存了。当进程结束时,这块内存会被释放掉,所以,我们一般情况下不用关心它。但是,如果你在编写代码的时候,创建了很多ByteBuffer,或者随着程序运行产生了很多 ByteBuffer,你也许想学习一些碎片化以及内存管理的技术。


4.引入OpenGL管道


把图形画到屏幕上之前,它需要在OpenGL管道中传递,这就需要使用称为着色器,这些着色器会告诉图形处理单元如何绘制数据。有两种类型的着色器,在绘制任何内容到屏幕之前,需要定义它们。


顶点着色器:生成每个顶点的最终位置,针对每个顶点,它都会执行一次,一旦最终位置确定了,OpenGL就可以这些可见顶点的集合组装成点,直线以及三角形。


片段着色器:为组成点,直线或者三角形的每个片段生成最终的颜色,针对每个片段,它都会执行一次,一个片段是一个小小的,单一的颜色的长方形区域,类似于计算机屏幕上的一个像素。


一旦最后的颜色生成了,OpenGL就会把它们写到一块称为帧缓冲区的内存块中,然后,Android会把这个帧缓冲区显示到屏幕上。


3 OpenGL管道概述

5.创建顶点着色器


在Android项目中创建raw文件,把着色器放入该文件夹下,便于引用。


示例simple_vertex_shader.glsl:

attribute vec4 a_Position;

void main()

{

gl_Position=a_Position;

}

这些着色器使用GLSL定义,GLSL是OpenGL的着色语言;这个着色语言的语法结构与C语言相似。


对于我们定义过的每个单一的定点,顶点着色器都会被调用一次;当它被调用的时候,它会在a_Position属性里接收当前顶点的位置,这个属性被定义为vec4类型。


一个vec4是包含了4个分量的向量;在位置的上下文中,可以认为这4个分量是X,Y,Z和W坐标,X,Y和Z对应一个三维位置,而W是一个特殊的坐标,后面会专门讲解W坐标,现在暂时略过。如果没有指定,默认情况下,OpenGL都是把向量的前三个坐标设为0,并把最后一个坐标设为1。


一个顶点会有几个属性,比如颜色和位置。关键词"attribute"就是把这些属性放进着色器的手段。


之后,可以定义main(),这是着色器的主要入口点;它所做的就是把前面定义过的位置复制到指定的输出变量gl_Position;这个着色器一定要给gl_Position赋值;OpenGL会把gl_Position中存储的位置当作顶点的最终位置,并把这些顶点组装成点,直线和三角形。


6.创建片段着色器


光栅化技术


移动设备的显示屏是由成千上万个小的,独立的部件组成,它们被称为像素;这些像素中的每一个都有能力显示几百万种不同颜色范围中的一种。然而,这实际上是一种视觉技巧:大多数显示器并不能真正创造几百万种颜色,所以每个像素通常是由三个单独的子构建构成的,它们发出红色,绿色,和蓝色的光,因为每个像素都非常小,人的眼睛会把红色,绿色和蓝色的光混合在一起,从而创造出巨量的颜色范围;把足够多的单独的像素放在一起,就能显示出多种颜色。


OpenGL通过“光栅化”的过程把每个点,直线及三角形分解成大量的小片段,它们可以映射到移动设备显示屏上,从而生成一幅图像。这些片段类似于显示屏上的像素,每个都包含单一的纯色。为了表示颜色,每个片段都有4个分量:其中红色,绿色,蓝色用来表示颜色,阿尔法分量用来表示透明度,


图4光栅化:生成片段


编写代码示例simple_fragment_shader.glsl:

precision mediump float;

uniform vec4 u_Color;

void main()

{

gl_FragColor=u_Color;

}

这个片段着色器中,文件顶部的第一行代码定义了所有浮点数据类型的默认精度。这就像Java代码中选择浮点数还是双精度浮点数一样。


可以选择lowp,mediump,highp,它们分别对应低精度,中精度及高精度;然而,只有某些硬件实现支持在片段着色器中使用highp。


细心阅读的可以发现为什么顶点着色器没有定义精度,其实顶点着色器同样也可以定义精度,但是对于一个顶点而言,精确度是最重要的,OpenGL设计者决定把顶点着色器的精度默认设置成最高级-highp。


你可能已经猜到了,高精度数据类型更加准确,但是这是以降低性能为代价的;对于片段着色器,出于最大兼容性的考虑,选择了mediump,这也是基于速度和质量的权衡。


这个片段着色器的剩余部分与早前定义的顶点着色器一样。不过这次我们要传递一个uniform,它叫做u_Color。它不像属性,每个顶点都要设置一个;一个uniform会让每个顶点都使用同一个值,除非我们在次改变它。如定点着色器中的位置所使用的属性一样,u_Color也是一个四分量向量,但是在颜色的上下文中,这四分量分别对应红色,绿色,蓝色和阿尔法。


接着我们定义了main(),它是这个着色器的住入口点,它把我们在uniform里定义的颜色复制到那个特殊的输出变量---gl_FragColor。着色器一定要给gl_FragColor赋值,OpenGL会使用这个颜色作为当前片段的最终颜色。


记住一个句话就完全了解片段着色器:片段着色器的主要目的就是告诉GPU每个片段的最终颜色应该是什么。


记住一个句话就完全了解顶点着色器:顶点着色器的主要目的就是确定每个顶点的最终位置。

Apply Projection and Camera View

问题是手机的屏幕不是方形的,但是openGL的坐标系是方形的,并且我们需要它们重合,所以会被拉伸。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值