没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
Real-Time Shader Programming
By Ron Fosner?
ISBN:1558608532
Morgan Kaufmann Publishers
?2003 (406 pages)
An indispensable reference for the game developer, graphics programmer, game artist, or
visualization programmer, to create countless real-time 3D effects.
Companion Web Site
?
Table of Contents
Back Cover
Comments
Table of Contents
Real-Time Shader Programming—Covering DirectX 9.0
Preface
Chapter 1
- Introduction
Chapter 2
- Preliminary Math
Chapter 3
- Mathematics of Lighting and Shading
Chapter 4
- Introduction to Shaders
Chapter 5
- Shader Setup in DirectX
Chapter 6
- Shader Tools and Resources
Chapter 7
- Shader Buffet
Chapter 8
- Shader Reference
Part I
- Vertex Shader Reference
Part II
- Pixel Shader Reference
References
About the CD-Rom
Index
List of Figures
List of Tables
List of Sidebars
Real-Time Shader Programming—
Covering DirectX 9.0
Ron Fosner
MORGAN KAUFMANN PUBLISHERS
AN IMPRINT OF ELSEVIER SCIENCE
Publishing Director: Diane D. Cerra
Publishing Services Manager: Edward Wade
Project Managment/Proofreading: Yonie Overton
Editorial Coordinator: Mona Buehler
Cover Design: Ross Carron Design
Text Design: Frances Baca Design
Composition: Proctor-Willenbacher
Technical Illustration: Dartmouth Publishing, Inc.
Copyeditor: Robert Fiske
Indexer: Richard Shrout
Interior Printer: Quebecor World Book Services
Cover Printer: Phoenix Color Corporation
About the cover: The cover image, "Pipe Dream" Demo, is taken from a real-time DirectX 9 Radeon
9700 version of "Pipe Dream" from Animusic's DVD entitled, ANIMUSIC: A Computer Animation Video
Album (http://www.animusic.com
). This was shown in offline-rendered form in the Electronic Theatre at
Siggraph 2001. All of the animation is data-driven from the original data from the Animusic demo.
However, the motion blur is done using shaders to dynamically alter the shape and lighting of the balls
(which are really a cylinder covered by two hemispheres) and the strings (which have a static string
shape and a plucked vibrating shape). For example, a ball's shape was distorted in the vertex shader by
stretching the length of the cylinder's axis from the ball's apparent velocity. The velocity was used to
calculate a vertex blurriness factor in the vertex shader, which was then passed to the pixel shader,
where the blurriness was used to spread out the specular highlights and make the highlight spread in
the direction of travel. The full details can be found on ATI's website. Thanks to David Gosselin of ATI
Research for being a good sport about providing me images on short notice.
Figure credits: (1) Figure 3–39 from "Digital Facial Engraving" by Victor Ostromoukhov, Proceedings of
SIGGRAPH `99, page 421. © 1999 Association for Computing Machinery. Reprinted with permission.
(2) Figure 3–40 from "Real-Time Hatching" by Emil Praun, Hugues Hoppe, Matthew Webb, and Adam
Finkelstein, Proceedings of SIGGRAPH `01, page 583. © 2001 Association for Computing Machinery.
Reprinted with permission. (3) Figure 3–42 from "A Non-Photorealistic Lighting Model for Automatic
Technical Illustration" by Amy Gooch, Bruce Gooch, Peter Shirley, and Elaine Cohen, Proceedings of
SIGGRAPH `98, page 452. © 1998 Association for Computing Machinery. Reprinted with permission.
(4) Figure 3–43 from Jet Set Radio Future.© 2002 Sega Enterprises, Inc. All rights reserved.
Designations used by companies to distinguish their products are often claimed as trademarks or
registered trademarks. In all instances in which Morgan Kaufmann Publishers is aware of a claim, the
product names appear in initial capital or all capital letters. Readers, however, should contact the
appropriate companies for more complete information regarding trademarks and registration.
Morgan Kaufmann Publishers
An Imprint of Elsevier Science
340 Pine Street, Sixth Floor
San Francisco, CA 94104–3205
http://www.mkp.com
Copyright © 2003 Elsevier Science (USA)
All rights reserved.
07 06 05 04 03 5 4 3 2 1
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or
by any means—electronic, mechanical, photocopying, or otherwise—without the prior written
permission of the publisher.
Library of Congress Control Number: 2002112069
1-55860-853-2
To my three exciting women—
Sue, Rachael, and Olivia.
Thank you.
About the Author
Ron Fosner has worked as a graphics programmer since the mid-1980s, first doing rudimentary 3D
graphics in assembly language, then learning OpenGL when it became available on Windows systems.
The lack of any good information on programming OpenGL on Windows led him to write the first widely
successful introductory book on OpenGL programming, OpenGL Programming for Windows 95 and
Windows NT. In addition to writing books, Ron has published numerous articles on 3D graphics and
code optimization and is a frequent lecturer at the Windows Developer (WinDev) and Game Developers
(GDC) conferences.
In the mid-1990s, the leading edge of real-time 3D graphics programming shifted from data visualization
to game programming and so did Ron, forming a graphics programming company. Since that time, Ron
has programmed four rendering engines, one facial animation engine, a stock market visualization tool,
and a video editing tool. Recently, he has been involved in programming internet tools for performance
and unit testing. In addition to programming, Ron tries to spread his knowledge on graphics and
programming by writing articles for numerous magazines, including Microsoft Systems Journal, Dr.
Dobb's, Game Developer Magazine, and Gamasutra, as well as articles for the Microsoft Developer
Network CDs.
Preface
One of the greatest things about being in the computer graphics industry is the sheer helpfulness of
people. Almost without fail people are willing to help each other out, overcome difficulties, and take the
time to share experiences, successes, and failures.
I got the idea for this book when I was chatting with Phil Taylor,
[1]
the product manager of the DirectX
SDK team at Microsoft. He was his usual ebullient self, going on about the new "shader" stuff that was
coming out with the next version of DirectX. He was also lamenting about how tough it was to get
people to understand what the advantage of shaders was, particularly when using textures as data. At
one point, he said something like, "I mean, it's not an image, it's just a matrix of four element values—it
could hold anything." It was at that point that I decided he was on to something. Only a small minority of
graphics programmers have actually done tricks with data masquerading as textures, and fewer
possess a solid understanding of how specifying a light, a material, and a triangle gets turned into a
rendered object. Shaders let you do that and more, but in order to use them to good effect, you have to
understand the power they place in your hands. To do that, you need knowledge.
My original vision for this book was along the lines of "a little book of shaders," but it didn't turn out that
way. The further I got involved in the writing, the more I discovered that you did need extensive
knowledge of not only the commands that were available to you and what they did, but how to assemble
them to suit your needs. I knew that I'd have to include a little section to discuss the math, but when I
started writing about the math involved with shading and illumination, with materials and lights, I knew I
had to back up and start from the beginning.
My goal is to provide you with the foundations that you need to write your own shaders. There's not only
a lot of theoretical stuff out there, but there's a golden opportunity to do your own thing and create your
own custom style. My goal is to give you enough knowledge so that you can feel comfortable writing
your own shaders. You should be able to feel free to go beyond the bounds of creating diffuse and
specular lighting, and write your own with three kinds of diffuse and five kinds of specular and an
emissive term based upon the proximity of the object to a power source. That is exactly what writing a
shader is all about. There's no mystery to it. There are a few conventions that you should follow, but the
one thing that I hope you'll learn is that what's "accepted," is just someone else's hack that got
perpetuated.
There's a story that Mike Abrash related once while he was working on Quake II. He and John Carmak
had gone to a convention and saw a competitor's game. The game had dynamic lighting effects—
something they hadn't thought necessary to implement at the time. Seeing it in action, however, made
them change their minds. So it got put on Mike's "to-do" list. A few weeks later, John asked if Mike had
gotten around to putting it in yet. "Nope. I bet I can do it in an hour," says John, and he goes away.
(John is known for some ferocious coding habits.) According to Mike, 54 minutes later, John says he's
done. He brings up the game, and fires a rocket down a long corridor. The corridor illuminates and it
follows the rocket down the length, and it looks great! John had taken the rocket's location, cast rays up,
down, left, and right, and pasted a spotlight texture at the intersection of the ray with any wall it found. It
wasn't realistic, but in the short time you got to see it, it was enough to give you the illusion of real
lighting. It was a hack, it looked good, and they shipped it. The moral of graphics programming is once it
looks good enough, it's good enough.
As my deadline for this book approaches, there's been no small upheaval in the shader world. Higher
level shading languages came too late for me to write about with any depth, so I focused on the low-
level language and how to construct shaders. In the last weeks before I finished writing, there's not one
but three competing high-level shader languages. It's still very much up in the air as to what the
standard language will look like, and there's considerable pressure building to make the language
independent of the hardware—that is, there'll be a software fallback—so that any shader program will
run on any modern hardware. We'll be free from "checking the caps bits" to see if we can use our
favorite shader. But now's not the time to wait! No matter what language you learn to write shaders in,
it's the experience and understanding from writing shaders that will carry over into any shading
language of the future. So let's get started!
[1]
My first contact with Phil was when someone was (I thought) heckling me during an OpenGL course at
the Computer Game Developers Conference. Even in those early days of the API wars, Phil was one of
the few with hearty integrity.
Chapter 1: Introduction
OVERVIEW
This is the true joy in life, being used for a purpose recognized by yourself as a mighty one. Being a
force of nature instead of a feverish, selfish little clod of ailments and grievances complaining that the
world will not devote itself to making you happy. I am of the opinion that my life belongs to the whole
community and as I live it is my privilege—my privilege—to do for it whatever I can. I want to be
thoroughly used up when I die, for the harder I work the more I love. I rejoice in life for its own sake. Life
is no brief candle to me; it is a sort of splendid torch which I've got a hold of for the moment and I want
to make it burn as brightly as possible before handing it on to future generations.
--George Bernard Shaw
Shader: A custom shading and lighting procedure that allows the motivated artist or programmer to
specify the rendering of a vertex or pixel.
剩余371页未读,继续阅读
资源评论
- zleisure2013-01-05感谢楼主分享,只可惜是英文的
- 晨曦熠熠2012-12-05去年学的时候下载的,一直忘了评论。当时很有帮助,感谢分享~
- LHZ5932013-06-14唉 可惜是英文。。。
- GCNB20122012-09-14唉 可惜是英文。。。
gaoguangxi888
- 粉丝: 1
- 资源: 2
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功