OpenGL+ES for iOS编程指南

需积分: 10 178 浏览量更新于2024-07-23 收藏 14.24MB PDF 举报

"OpenGL+ES英文影印版，一本关于移动平台图形编程的专业书籍，适合iOS开发者学习使用。" OpenGL和OpenGL ES是计算机图形学中广泛使用的API，用于在各种平台上创建2D和3D图形。OpenGL ES是OpenGL的精简版本，特别针对嵌入式系统，如智能手机和平板电脑，特别是在iOS设备上。本书《Pro OpenGL ES for iOS》旨在帮助开发者深入了解和掌握在iOS平台上使用OpenGL ES进行图形编程的技术。书中内容涵盖了一系列关键主题，从计算机图形学的基础概念到高级应用，包括： 1. **计算机图形学历史与现在**：第一章介绍了计算机图形学的发展历程，帮助读者理解这一领域的重要性以及它如何随着时间演变。 2. **数学基础**：第二章深入讲解了图形编程中必不可少的数学知识，如向量、矩阵运算、几何变换等，这些是构建3D世界的基石。 3. **构建3D世界**：第三章教授如何使用OpenGL ES构建基本的3D环境，包括坐标系统、视口和投影设定。 4. **光照处理**：第四章讨论如何在3D场景中添加光照效果，使图形更逼真。 5. **纹理映射**：第五章涵盖了纹理的应用，包括加载、应用纹理以及纹理坐标处理，以增加图形的细节和视觉吸引力。 6. **混合与透明度**：第六章探讨了对象间的混合操作和透明度控制，这对于创建复杂的叠加效果至关重要。 7. **渲染杂项**：第七章包含了一些高级渲染技术，如深度测试、多边形偏移和雾化等。 8. **整合应用**：第八章展示了如何将前面学习的知识整合到一个完整的项目中，实现一个功能完善的3D应用。 9. **性能优化**：第九章讨论了性能问题和解决方案，包括内存管理、渲染效率提升等，这对于移动设备上的图形程序尤其重要。 10. **OpenGL ES 2.0，着色器与更多**：第十章涵盖了OpenGL ES 2.0的新特性，特别是着色器语言GLSL，这是现代图形编程的核心部分。此外，书中的作者简介、技术审阅者信息、致谢和索引提供了对整个作品背景和贡献者的了解，方便读者查阅和参考。通过这本书，读者可以系统地学习OpenGL ES，并具备在iOS平台上开发高性能、高质量图形应用的能力。无论是对于游戏开发、可视化工具还是科学模拟，OpenGL ES都是强大的图形接口，而这本书正是掌握它的理想指南。

CHAPTER 1: Computer Graphics: From Then to Now

The 1990s brought the T1000 ‘‘liquid metal’’ terminator in

Terminator 2: Judgment Day

the first completely computer-generated full-length feature film of

Toy Story

, believable

animated dinosaurs in

Jurassic Park

, and James Cameron’s

Titanic

, all of which helped

solidified CG as a common tool in the Hollywood director’s arsenal.

By the decade’s end, it would be hard to find any films that didn’t have computer

graphics as part of the production in either actual effects or in postproduction to help

clean up various scenes. New techniques are still being developed and applied in ever

more spectacular fashion, as in Disney’s delightful

Up!

or James Cameron’s beautiful

Avatar

Now, once again, take out your i-device and realize what a little technological marvel it

is. Feel free to say ‘‘wow’’ in hushed, respectful tones.

Toolkits

All of the 3D wizardry referenced earlier would never have been possible without

software. Many CG software programs are highly specialized, and others are more

general purpose, such as OpenGL ES, the focus of this book. So, what follows are a few

of the many toolkits available.

OpenGL

Open Graphics Library (OpenGL) came out of the pioneering efforts of SGI, the maker of

high-end graphics workstations and mainframes. Its own proprietary graphics

framework, IRIS-GL, had grown into a de-facto standard across the industry. To keep

customers as competition increased, SGI opted to turn IRIS-GL into an open framework

so as to strengthen their reputation as the industry leader. IRIS-GL was stripped of non-

graphics-related functions and hardware-dependent features, renamed OpenGL, and

released in early 1992. As of this writing, version 4.1 is the most current one available.

As small handheld devices became more common, OpenGL for Embedded Systems

(OpenGL ES) was developed, which was a stripped-down version of the desktop

version. It removed many of the more redundant API calls while simplifying other

elements. making it run efficiently on lower-power CPUs. As a result, it has been widely

adopted across many platforms, such as Android, iOS, Nintendo 3DS, and BlackBerry

(OS 5.0 and newer).

There are two main flavors of OpenGL ES, 1.

and 2.

. Many devices support both. 1.

is the higher-level variant, based on the original OpenGL specification. Version 2.

(yes, I

know it’s confusing) is targeted toward more specialized rendering chores that can be

handled by programmable graphics hardware.

Direct3D

Direct3D (D3D) is Microsoft’s answer to OpenGL and is heavily oriented toward game

developers. In 1995, Microsoft bought a small company called RenderMorphics that

CHAPTER 1: Computer Graphics: From Then to Now

specialized in creating a 3D framework named RealityLab for writing games. RealityLab

was turned into Direct3D and first released in the summer of 1996. Even though it was

proprietary to Windows-based systems, it has a huge user base across all of Microsoft’s

platforms: Windows, Windows 7 Mobile, and even Xbox. There are constant ongoing

debates between the OpenGL and Direct3D camps as to which is more powerful,

flexible, and easier to use. Other factors include how quickly hardware manufacturers

can update their drivers to support new features, ease of understanding (Direct3D uses

Microsoft’s COM interface that can be very confusing for newcomers), stability, and

industry support.

The Other Guys

While OpenGL and Direct3D remain at the top of the heap when it comes to both

adoption and features, the graphics landscape is littered with numerous other

frameworks, many which are supported on today’s devices.

In the computer graphics world, graphics libraries come in two very broad flavors: low-

level rendering mechanisms represented by OpenGL and Direct3D and high-level

systems typically found in game engines that concentrate on resource management with

special extras that extend to common gameplay elements (sound, networking, scoring,

and so on). The latter are usually built on top of one of the former for the 3D portion. And

if done well, the higher-level systems might even be abstracted enough to make it

possible to work with both GL and D3D.

QuickDraw 3D

An example of a higher-level general-purpose library is QuickDraw 3D (QD3D). A 3D

sibling to Apple’s 2D QuickDraw (used in pre-OS-X days), QD3D had an elegant means

of generating and linking objects in an easy-to-understand hierarchical fashion (

a scene-

graph

). It likewise had its own file format for loading 3D models and a standard viewer

and was platform independent. The higher-level part of QD3D would calculate the scene

and determine how each object and, in turn, each piece of each object would be shown

on a 2D drawing surface. Underneath QD3D there was a very thin layer called RAVE that

would handle device-specific rendering of these bits.

Users could go with the standard version of RAVE, which would render the scene as

expected. But more ambitious users could write their own that would display the scene

in a more artistic fashion. For example, one company generated the RAVE output so as

to look like their objects were hand-painted on the side of a cave. It was very cool when

you could take this modern version of a cave drawing and spin it around. The plug-in

architecture also made QD3D highly portable to other machines. When potential users

balked at using QD3D since it had no hardware solution on PCs, a version of RAVE was

produced that would use the hardware acceleration available for Direct3D by actually

using its competitor as its rasterizer. Sadly, QD3D was almost immediately killed on the

second coming of Steve Jobs, who determined that OpenGL should be the 3D standard

for Macs in the future. This was an odd statement because QD3D was not a competitor

to the other but an add-on that made the lives of programmers much easier. After Jobs

CHAPTER 1: Computer Graphics: From Then to Now

refused requests to make QD3D open source, the Quesa project was formed to re-

create as much as possible the original library, which is still being supported at the time

of this writing. And to nobody’s surprise, Quesa uses OpenGL as its rendering engine.

A disclaimer here: I wrote the RAVE/Direct3D layer of QD3D only to have the project

canceled a few days after going ‘‘gold master’’ (ready to ship).

OGRE

Another scene-graph system is Object-oriented Rendering Engine (OGRE). First

released in 2005, OGRE can use both OpenGL and Direct3D as the low-level rasterizing

solution, while offering users a stable and free toolkit used in many commercial

products. The size of the user community is impressive. A quick peek at the forums

shows more than 6,500 topics in the General Discussion section alone at the time of this

writing.

OpenSceneGraph

Recently released for iOS devices, OpenSceneGraph does roughly what QuickDraw 3D

did, by providing a means of creating your objects on a higher level, linking them

together, and performing scene management duties and extra effects above the

OpenGL layer. Other features include importing multiple file formats, text support,

particle effects (used for sparks, flames, or clouds), and the ability to display video

content in your 3D applications. Knowledge of OpenGL is highly recommended,

because many of the OSG functions are merely thin wrappers to their OpenGL

counterparts.

Unity3D

Unlike OGRE, QD3D, or OpenSceneGraph, Unity3D is a full-fledged game engine. The

difference lies in the scope of the product. Whereas the first two concentrated on

creating a more abstract wrapper around OpenGL, game engines go several steps

further, supplying most if not all of the other supporting functionality that games would

typically need such as sound, scripting, networked extensions, physics, user interface,

and score-keeping modules. In addition, a good engine will likely have tools to help

generate the assets and be platform independent.

Unity3D has all of these so would be overkill for many smaller projects. Also, being a

commercial product, the source is not available, and it is not free to use, costing a

modest amount (compared to other products in the past that could charge $100,000

or more).

And Still Others

Let’s not ignore A6, Adventure Game Studio, C4, Cinder, Cocos3d, Crystal Space, VTK,

Coin3D, SDL, QT, Delta3D, Glint3D, Esenthel, FlatRedBall, Horde3D, Irrlicht,

CHAPTER 1: Computer Graphics: From Then to Now

Leadwerks3D, Lightfeather, Raydium, Panda3D (from Disney Studios and CMU), Torque

(available for iOS), and many others. Although they’re powerful, one drawback of using

game engines is that more often than not, your world is executed in their environment.

So if you need a specific subtle behavior that is unavailable, you may be out of luck.

That brings me back to the topic of this book.

Back to the Waltz of the Two Cubes

Up through iOS4, Apple saw OpenGL as more of a general-purpose framework. But

starting with iOS5, they wanted to emphasize it as a perfect environment for game

development. That is why, for example, the project icon in the wizard is titled ‘‘OpenGL

Game,’’ where previously it was ‘‘OpenGL ES Application.’’ That also explains why the

e x a m p l e e x er c is e pu s h es t he b et t er p e r f o r m i ng ----- bu t c o n s i d e ra b ly m or e cu m be r s o m e -----

OpenGL ES 2 environment, while ignoring the easier version that is the subject of

this book.

Note Also starting with iOS5, Apple has added a number of special helper-objects in their

new GLKit framework that take over some of the common duties developers had to do

themselves early on. These tasks include image loading, 3D-oriented math operations, creating

a special OpenGL view, and managing special effects.

With that in mind, I’ll step into 2.0-land every once in a while, such as via the example

app described below, because that’s all we have for now. Detailed discussions of 2.0

will be reserved for the last chapter, because it really is a fairly advanced topic for the

scope of this book.

A Closer Look

The wizard produces six main files not including those of the plist and storyboards. Of

these, there are the two for the view controller, two for the application delegate, and two

mysterious looking things called shader.fsh and shader.vsh.

The shader files are unique to OpenGL ES 2.0 and are used to fine-tune the look of your

scenes. They serve as small and very fast programs that execute on the graphics card

itself, using their own unique language that resembles C. They give you the power to

specify exactly how light and texture should show up in the final image. Unfortunately,

OpenGL ES 2.0 requires shaders and hence a somewhat steeper learning curve, while

the easier and more heavily used version 1.1 doesn’t use shaders, settling for a few

standard lighting and shading effects (called a ‘‘fixed function’’ pipeline). The shader-

based applications are most likely going to be games where a visually rich experience is

as important as anything else, while the easier 1.1 framework is just right for simple

games, business graphics, educational titles, or any other apps that don’t need to have

perfect atmospheric modeling.

CHAPTER 1: Computer Graphics: From Then to Now

The application delegate has no active code in it, so we can ignore it. The real action

takes place in the viewController via three main sections. The first initializes things using

some of the standard view controller methods we all know and love, the second serves

to render and animate the image, and the third section manages these shader things.

Don’t worry if you don’t get it completely, because this example is merely intended to

give you a general overview of what a basic OpenGL ES program looks like.

Note All of these exercises are available on the Apress site, including additional bonus

exercises that may not be in the book.

You will notice that throughout all of the listings, various parts of the code are marked

with a numbered comment. The numbers correspond to the descriptions following the

listing and that highlight various parts of the code.

Listing 1-1. The initialization of the wizard-generated view controller.

#import "TwoCubesViewController.h"

#define BUFFER_OFFSET(i) ((char *)NULL + (i))

// Uniform index.

Enum //1

{

UNIFORM_MODELVIEWPROJECTION_MATRIX,

UNIFORM_NORMAL_MATRIX,

NUM_UNIFORMS

};

GLint uniforms[NUM_UNIFORMS];

// Attribute index.

enum

{

ATTRIB_VERTEX,

ATTRIB_NORMAL,

NUM_ATTRIBUTES

};

GLfloat gCubeVertexData[216] = //2

{

// Data layout for each line below is:

// positionX, positionY, positionZ, normalX, normalY, normalZ,

0.5f, -0.5f, -0.5f, 1.0f, 0.0f, 0.0f,

0.5f, 0.5f, -0.5f, 1.0f, 0.0f, 0.0f,

0.5f, -0.5f, 0.5f, 1.0f, 0.0f, 0.0f,

0.5f, 0.5f, 0.5f, 1.0f, 0.0f, 0.0f,

0.5f, 0.5f, -0.5f, 1.0f, 0.0f, 0.0f,

0.5f, 0.5f, -0.5f, 0.0f, 1.0f, 0.0f,

-0.5f, 0.5f, -0.5f, 0.0f, 1.0f, 0.0f,

0.5f, 0.5f, 0.5f, 0.0f, 1.0f, 0.0f,

剩余361页未读，继续阅读

Yolly

粉丝: 1

OpenGL+ES for iOS编程指南

最新资源