DOCSLIB.ORG

Graphics Library Programming Guide Volume I

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Graphics Library Programming Guide Volume I Graphics Library Programming Guide Volume I Document Number 007-1210-060 Contributors Written by Patricia McLendon Illustrated by Dan Young, Howard Look, and Patricia McLendon Edited by Steven W. Hiatt Production by Derrald Vogt Engineering contributions by John Airey, Kurt Akeley, Dan Baum, Rosemary Chang, Howard Cheng, Tom Davis, Bob Drebin, Ben Garlick, Mark Grossman, Michael Jones, Seth Katz, Phil Karlton, George Kong, Erik Lindholm, Howard Look, Rob Mace, Martin McDonald, Jackie Neider, Mark Segal, Dave Spalding, Gary Tarolli, Vince Uttley, and Rolf Van Widenfelt. © Copyright 1992, Silicon Graphics, Inc.— All Rights Reserved This document contains proprietary and confidential information of Silicon Graphics, Inc. The contents of this document may not be disclosed to third parties, copied, or duplicated in any form, in whole or in part, without the prior written permission of Silicon Graphics, Inc. Restricted Rights Legend Use, duplication, or disclosure of the technical data contained in this document by the Government is subject to restrictions as set forth in subdivision (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS 52.227-7013 and/or in similar or successor clauses in the FAR, or in the DOD or NASA FAR Supplement. Unpublished rights reserved under the Copyright Laws of the United States. Contractor/manufacturer is Silicon Graphics, Inc., 2011 N. Shoreline Blvd., Mountain View, CA 94039-7311. Graphics Library Programming Guide Document Number 007-1210-060 Silicon Graphics, Inc. Mountain View, California Silicon Graphics, the Silicon Graphics logo, and IRIS are registered trademarks and IRIS Graphics Library, Geometry Engine, Geometry Pipeline, IRIX, 4D, MicroPixel, Personal IRIS, IRIS Indigo, XS, XS24, Elan, RealityEngine, and SkyWriter are trademarks of Silicon Graphics, Inc. Ada is a registered trademark of the Ada Joint Program of the United States of America Ethernet is a registered trademark of Xerox Corporation OSF/Motif is a trademark of the Open Software Foundation Spaceball is a trademark of Spatial Systems, Inc. UNIX is a registered trademark of AT&T Bell Labs X Window System and Athena Widgets are trademarks of the Massachusetts Institute of Technology. Contents Introduction.................................................................................................xxi How to Use This Guide.............................................................. xxii How to Use the Sample Programs.......................... xxii Typographical Conventions ................................... xxiii What this Guide Contains....................................... xxiii How to Use the On-line Manual Pages.....................................xxv Using Man Pages from the Toolchest......................xxv Using Man Pages from an IRIX Shell ......................xxv Suggestions for Further Reading ............................................. xxvi 1. Graphics Development Environment...................................................1-1 1.1 Using the Graphics Library and System Libraries ...................1-1 1.1.1 System Libraries ..........................................................1-2 1.1.2 Include Files .................................................................1-2 1.2 Using the X Window System.......................................................1-2 1.3 Programming in C.........................................................................1-4 1.3.1 Using the ANSI C Standard.......................................1-4 1.3.2 Compiling C Programs...............................................1-4 1.4 GL Program Structure ..................................................................1-5 1.4.1 Initializing the System ................................................1-6 1.4.2 Getting Graphics Information ...................................1-7 1.4.3 Global State Attributes .............................................1-10 1.4.4 Exiting the Graphics Environment .........................1-10 iii 2. Drawing ........................................................................................................2-1 2.1 Drawing with the GL....................................................................2-1 2.1.1 Vertex Subroutines......................................................2-2 2.1.2 Points.............................................................................2-7 2.1.3 Lines ..............................................................................2-8 2.1.4 Polygons .....................................................................2-12 2.1.5 Point-Sampled Polygons..........................................2-17 2.1.6 Meshes ........................................................................2-21 2.1.7 Controlling Polygon Rendering..............................2-29 2.2 Old-Style Drawing ......................................................................2-30 2.2.1 Basic Shapes ...............................................................2-31 2.2.2 Nonrecommended Old-Style Subroutines ............2-37 3. Characters and Fonts...............................................................................3-1 3.1 Drawing Characters......................................................................3-2 3.1.1 Determining the Current Character Position..........3-2 3.1.2 Drawing Character Strings ........................................3-3 3.1.3 Clipping Character Strings ........................................3-3 3.1.4 Getting Character Information..................................3-4 3.2 Creating a Font ..............................................................................3-7 3.2.1 Defining the Font.........................................................3-9 3.2.2 Selecting the Font ......................................................3-12 3.2.3 Querying the System for Font Information...........3-14 4. Display and Color Modes ........................................................................4-1 4.1 Color Display.................................................................................4-2 4.1.1 Bitplanes .......................................................................4-3 4.1.2 Dithering.......................................................................4-4 4.2 RGB Mode ......................................................................................4-5 4.2.1 Setting and Getting the Current Color in RGB Mode................................................................4-7 4.3 Gouraud Shading ..........................................................................4-8 iv 4.4 Color Map Mode .........................................................................4-15 4.4.1 Setting the Current Color in Color Map Mode...................................................4-17 4.4.2 Getting Color Information in Color Map Mode...................................................4-18 4.4.3 Gouraud Shading in Color Map Mode ..................4-19 4.4.4 Blinking.......................................................................4-21 4.5 Onemap and Multimap Modes.................................................4-22 4.6 Gamma Correction......................................................................4-23 5. User Input ....................................................................................................5-1 5.1 Event Handling .............................................................................5-1 5.1.1 Queueing ......................................................................5-3 5.1.2 Polling ...........................................................................5-7 5.2 Input Devices ...............................................................................5-10 5.2.1 Buttons ........................................................................5-11 5.2.2 Valuators ....................................................................5-12 5.2.3 Keyboard Devices .....................................................5-13 5.2.4 Window Manager Tokens........................................5-14 5.2.5 Spaceball Devices...................................................5-15 5.2.6 Controlling Devices ..................................................5-16 5.3 Video Control...............................................................................5-17 6. Animation.....................................................................................................6-1 6.1 Understanding How Animation Works ....................................6-1 6.1.1 Single Buffer Mode .....................................................6-2 6.1.2 Double Buffer Mode ...................................................6-2 6.2 Creating an Animation.................................................................6-2 6.2.1 Setting Modes for Animation ....................................6-3 6.2.2 Swapping Buffers ........................................................6-3 6.2.3 Swapping Multiple Buffers........................................6-3 6.2.4 Maximizing Animation Performance.......................6-6 v 7. Coordinate Transformations ..................................................................7-1 7.1 Coordinate Systems ......................................................................7-2 7.2 Projection Transformations..........................................................7-4 7.2.1 Perspective Projection.................................................7-4 7.2.2 Window Projection .....................................................7-9 7.2.3 Orthographic Projections .........................................7-10
Load more

Recommended publications
  • 20 Years of Opengl
    20 Years of OpenGL Kurt Akeley © Copyright Khronos Group, 2010 - Page 1 So many deprecations! • Application-generated object names • Depth texture mode • Color index mode • Texture wrap mode • SL versions 1.10 and 1.20 • Texture borders • Begin / End primitive specification • Automatic mipmap generation • Edge flags • Fixed-function fragment processing • Client vertex arrays • Alpha test • Rectangles • Accumulation buffers • Current raster position • Pixel copying • Two-sided color selection • Auxiliary color buffers • Non-sprite points • Context framebuffer size queries • Wide lines and line stipple • Evaluators • Quad and polygon primitives • Selection and feedback modes • Separate polygon draw mode • Display lists • Polygon stipple • Hints • Pixel transfer modes and operation • Attribute stacks • Pixel drawing • Unified text string • Bitmaps • Token names and queries • Legacy pixel formats © Copyright Khronos Group, 2010 - Page 2 Technology and culture © Copyright Khronos Group, 2010 - Page 3 Technology © Copyright Khronos Group, 2010 - Page 4 OpenGL is an architecture Blaauw/Brooks OpenGL SGI Indy/Indigo/InfiniteReality Different IBM 360 30/40/50/65/75 NVIDIA GeForce, ATI implementations Amdahl Radeon, … Code runs equivalently on Top-level goal Compatibility all implementations Conformance tests, … It’s an architecture, whether Carefully planned, though Intentional design it was planned or not . mistakes were made Can vary amount of No feature subsetting Configuration resource (e.g., memory) Config attributes (e.g., FB) Not a formal
    [Show full text]
  • Realityengine Graphics
    RealityEngine Graphics Kurt Akeley Silicon Graphics Computer Systems Abstract Silicon Graphics Iris 3000 (1985) and the Apollo DN570 (1985). Toward the end of the ®rst-generation period advancesin technology The RealityEngineTM graphics system is the ®rst of a new genera- allowed lighting, smooth shading, and depth buffering to be imple- tion of systems designed primarily to render texture mapped, an- mented, but only with an order of magnitude less performance than tialiased polygons. This paper describes the architecture of the was available to render ¯at-shaded lines and polygons. Thus the RealityEngine graphics system, then justi®es some of the decisions target capability of these machines remained ®rst-generation. The made during its design. The implementation is near-massively par- Silicon Graphics 4DG (1986) is an example of such an architecture. allel, employing 353 independent processors in its fullest con®gura- tion, resulting in a measured ®ll rate of over 240 million antialiased, Because ®rst-generation machines could not ef®ciently eliminate texture mapped pixels per second. Rendering performance exceeds hidden surfaces, and could not ef®ciently shade surfaces even if the 1 million antialiased, texture mapped triangles per second. In ad- application was able to eliminate them, they were more effective dition to supporting the functions required of a general purpose, at rendering wireframe images than at rendering solids. Begin- high-end graphics workstation, the system enables realtime, ªout- ning in 1988 a second-generation of graphics systems, primarily the-windowº image generation and interactive image processing. workstations rather than terminals, became available. These ma- chines took advantage of reduced memory costs and the increased availability of ASICs to implement deep framebuffers with multiple CR Categories and Subject Descriptors: I.3.1 [Computer rendering processors.
    [Show full text]
  • Vers Des Supports D'exécution Capables D'exploiter Les Machines
    Vers des supports d’exécution capables d’exploiter les machines multicœurs hétérogènes Cédric Augonnet To cite this version: Cédric Augonnet. Vers des supports d’exécution capables d’exploiter les machines multicœurs hétérogènes. [Travaux universitaires] 2008, pp.48. inria-00289361 HAL Id: inria-00289361 https://hal.inria.fr/inria-00289361 Submitted on 20 Jun 2008 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. M´emoirede MASTER RECHERCHE pr´esent´epar C´edricAugonnet Vers des supports d’execution´ capables d’exploiter les machines multicœurs het´ erog´ enes` Encadrement : Raymond Namyst Fevrier´ – Juin 2008 Laboratoire Bordelais de Recherche en Informatique (LaBRI) INRIA Bordeaux Universit´eBordeaux 1 Table des mati`eres Remerciements v 1 Introduction 1 2 Etat´ de l’art 3 2.1 Architecture : du multicœur a` l’het´ erog´ ene` . 3 2.1.1 Adoption du multicœur . 3 2.1.2 Utilisation d’accel´ erateurs´ . 4 2.1.3 Vers un multicœur het´ erog´ ene` . 5 2.2 Programmation multicœur homogene` . 5 2.2.1 Gestion explicite du parallelisme´ . 6 2.2.2 Se reposer sur un langage . 6 2.3 Programmation d’accel´ erateurs´ . 6 2.3.1 GPGPU .
    [Show full text]
  • Applications of Pixel Textures in Visualization and Realistic Image Synthesis
    Applications of Pixel Textures in Visualization and Realistic Image Synthesis Wolfgang Heidrich, Rudiger¨ Westermann, Hans-Peter Seidel, Thomas Ertl Computer Graphics Group University of Erlangen fheidrich,wester,seidel,[email protected] Abstract which can be used for volume rendering, and the imaging subset, a set of extensions useful not only for image-processing, have been With fast 3D graphics becoming more and more available even on added in this version of the specification. Bump mapping and pro- low end platforms, the focus in developing new graphics hardware cedural shaders are only two examples for features that are likely to is beginning to shift towards higher quality rendering and addi- be implemented at some point in the future. tional functionality instead of simply higher performance imple- On this search for improved quality it is important to identify a mentations of the traditional graphics pipeline. On this search for powerful set of orthogonal building blocks to be implemented in improved quality it is important to identify a powerful set of or- hardware, which can then be flexibly combined to form new algo- thogonal features to be implemented in hardware, which can then rithms. We think that the pixel texture extension by Silicon Graph- be flexibly combined to form new algorithms. ics [9, 12] is a building block that can be useful for many applica- Pixel textures are an OpenGL extension by Silicon Graphics that tions, especially when combined with the imaging subset. fits into this category. In this paper, we demonstrate the benefits of In this paper, we use pixel textures to implement four different this extension by presenting several different algorithms exploiting algorithms for applications from visualization and realistic image its functionality to achieve high quality, high performance solutions synthesis: fast line integral convolution (Section 3), shadow map- for a variety of different applications from scientific visualization ping (Section 4), realistic fog models (Section 5), and finally en- and realistic image synthesis.
    [Show full text]
  • Rasterization Pipeline Aaron Lefohn - Intel / University of Washington Mike Houston – AMD / Stanford
    A Trip Down The (2003) Rasterization Pipeline Aaron Lefohn - Intel / University of Washington Mike Houston – AMD / Stanford Winter 2011 – Beyond Programmable Shading 1 Acknowledgements In addition to a little content by Aaron Lefohn and Mike Houston, this slide deck is based on slides from • Tomas Akenine-Möller (Lund University / Intel) • Eric Demers (AMD) • Kurt Akeley (Microsoft/Refocus Imaging) - CS248 Autumn Quarter 2007 Winter 2011 – Beyond Programmable Shading 2 This talk • Overview of the real-time rendering pipeline available in ~2003 corresponding to graphics APIs: – DirectX 9 – OpenGL 2.x • To clarify – There are many rendering pipelines in existence – REYES – Ray tracing – DirectX11 – … – Today’s lecture is about the ~2003 GPU hardware rendering pipeline Winter 2011 – Beyond Programmable Shading 3 If you need a deeper refresher • See Kurt Akeley’s CS248 from Stanford – http://www-graphics.stanford.edu/courses/cs248-07/schedule.php – This material should serve as a solid refresher • For an excellent “quick” review of programmable shading in OpenCL, see Andrew Adams’ lecture at the above link • GLSL tutorial – http://www.lighthouse3d.com/opengl/glsl/ • Direct3D 9 tutorials – http://www.directxtutorial.com/ – http://msdn.microsoft.com/en-us/library/bb944006(v=vs.85).aspx • More references at the end of this deck Winter 2011 – Beyond Programmable Shading 4 The General Rasterization Pipeline Winter 2011 – Beyond Programmable Shading 5 Rendering Problem Statement • Rendering is the process of creating an image from a computer representation
    [Show full text]
  • Kurt Akeley Interview
    Kurt Akeley Interview Interviewer by: Dag Spicer Recorded: November 5, 2010 Mountain View, California CHM Reference number: X5984.2011 © 2010 Computer History Museum Kurt Akeley Interview Dag Spicer: Okay. So today is Friday, November the 11th, 2010 in Mountain View, California at the Computer History Museum and we’re delighted today to have Kurt Akeley, one of the co-founders of Silicon Graphics--a world leader in computer graphic systems, with us today. Thank you for being with us, Kurt. Kurt Akeley: You’ve very welcome. Spicer: I wanted to ask you what it was like at SGI [Silicon Graphics, Inc.] in the early days in terms of the work ethic and company culture. Akeley: Yeah. Well, we … there was a strong work ethic. We all worked really hard, but I think, right from the beginning we also worked hard and played hard. And it was a very collegial environment. We were-- a lot of us weren’t very old-- I mean, Jim Clark, the real founder of the company was, I don’t know, 35 or something I forget how old at that point. But the rest of us were quite a bit younger. A lot of us were just either graduate students or very recently graduate students. So young, not so much family, and so I think the company became our home as well as our place of work. And Jim, at least to me, [became] very much of a father figure. He was out to do something great and he was very ambitious about it but he was- - I think he really enjoyed building this little family and kind of bringing us with him where we were going.
    [Show full text]
  • Procedural Representations for Computer Animation
    Encapsulated Models: Procedural Representations for Computer Animation DISSERTATION Presented in Partial Fulfillment of the Requirements for the Degree Doctor of Philosophy in the Graduate School of The Ohio State University By Stephen Forrest May, B.S., M.S. ***** The Ohio State University 1998 Dissertation Committee: Approved by Prof. Wayne E. Carlson, Adviser Prof. Richard E. Parent Adviser Prof. Neelam Soundarajan Department of Computer and Prof. Charles A. Csuri Information Science MANY PAGES DISCARDED 1.1.2 Historical Development of Computer Animation Systems Traditionally, animation systems have neatly filed themselves into one of two distinctly different classifications: scripting and interactive. Modern systems still can be classified in this manner, although increasingly the distinction between the two classifications is being blurred. 16 1.1.2.1 Scripting Systems The first computer animations were produced by writing programs to generate the an- imation using general purpose programming languages (e.g., Fortran). General purpose languages are flexible and inherently allow programmers to take advantage of conventional programming mechanisms (e.g., variables, subroutines, conditional statement execution, it- eration) and techniques (e.g., structured programming, object-oriented design, recursion) to produce animation. The main disadvantage of this approach is that many elements needed to generate animations (e.g., specifying geometric shapes, building hierarchies, generating output for renderers, applying transformations to objects) have to be reimplemented for each animation. The amount of work required to provide the underlying framework can easily outweigh the programming needed that is unique to the production of the animation task at hand. In response to the problems of using general purpose programming languages, re- searchers developed specialized programming languages, procedural animation languages, designed for the task of computer animation [30, 47, 60, 64, 65, 80, 104, 111, 113].
    [Show full text]
  • Reality Engine Graphics
    RealityEngine Graphics Kurt Akeley Silicon Graphics Computer Systems Abstract Silicon Graphics Iris 3000 (1985) and the Apollo DN570 (1985). Toward the end of the ®rst-generation period advancesin technology The RealityEngineTM graphics system is the ®rst of a new genera- allowed lighting, smooth shading, and depth buffering to be imple- tion of systems designed primarily to render texture mapped, an- mented, but only with an order of magnitude less performance than tialiased polygons. This paper describes the architecture of the was available to render ¯at-shaded lines and polygons. Thus the RealityEngine graphics system, then justi®es some of the decisions target capability of these machines remained ®rst-generation. The made during its design. The implementation is near-massively par- Silicon Graphics 4DG (1986) is an example of such an architecture. allel, employing 353 independent processors in its fullest con®gura- tion, resulting in a measured ®ll rate of over 240 million antialiased, Because ®rst-generation machines could not ef®ciently eliminate texture mapped pixels per second. Rendering performance exceeds hidden surfaces, and could not ef®ciently shade surfaces even if the 1 million antialiased, texture mapped triangles per second. In ad- application was able to eliminate them, they were more effective dition to supporting the functions required of a general purpose, at rendering wireframe images than at rendering solids. Begin- high-end graphics workstation, the system enables realtime, ªout- ning in 1988 a second-generation of graphics systems, primarily the-windowº image generation and interactive image processing. workstations rather than terminals, became available. These ma- chines took advantage of reduced memory costs and the increased availability of ASICs to implement deep framebuffers with multiple CR Categories and Subject Descriptors: I.3.1 [Computer rendering processors.
    [Show full text]
  • Applications of Pixel Textures in Visualization and Realistic Image Synthesis
    Applications of Pixel Textures in Visualization and Realistic Image Synthesis Wolfgang Heidrich, Rudiger¨ Westermann, Hans-Peter Seidel, Thomas Ertl Computer Graphics Group University of Erlangen heidrich,wester,seidel,ertl ¡ @informatik.uni-erlangen.de Abstract which can be used for volume rendering, and the imaging subset, a set of extensions useful not only for image-processing, have been With fast 3D graphics becoming more and more available even on added in this version of the specification. Bump mapping and pro- low end platforms, the focus in developing new graphics hardware cedural shaders are only two examples for features that are likely to is beginning to shift towards higher quality rendering and addi- be implemented at some point in the future. tional functionality instead of simply higher performance imple- On this search for improved quality it is important to identify a mentations of the traditional graphics pipeline. On this search for powerful set of orthogonal building blocks to be implemented in improved quality it is important to identify a powerful set of or- hardware, which can then be flexibly combined to form new algo- thogonal features to be implemented in hardware, which can then rithms. We think that the pixel texture extension by Silicon Graph- be flexibly combined to form new algorithms. ics [9, 12] is a building block that can be useful for many applica- Pixel textures are an OpenGL extension by Silicon Graphics that tions, especially when combined with the imaging subset. fits into this category. In this paper,
    [Show full text]
  • Achieving Near-Correct Focus Cues Using Multiple Image Planes
    ACHIEVING NEAR-CORRECT FOCUS CUES USING MULTIPLE IMAGE PLANES A DISSERTATION SUBMITTED TO THE DEPARTMENT OF ELECTRICAL ENGINEERING AND THE COMMITTEE ON GRADUATE STUDIES OF STANFORD UNIVERSITY IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY Kurt Akeley June 2004 c Copyright by Kurt Akeley 2004 All Rights Reserved ii I certify that I have read this dissertation and that, in my opinion, it is fully adequate in scope and quality as a dissertation for the degree of Doctor of Philosophy. Patrick Hanrahan (Principal Adviser) I certify that I have read this dissertation and that, in my opinion, it is fully adequate in scope and quality as a dissertation for the degree of Doctor of Philosophy. Martin S. Banks (Visual Space Perception Laboratory University of California, Berkeley) I certify that I have read this dissertation and that, in my opinion, it is fully adequate in scope and quality as a dissertation for the degree of Doctor of Philosophy. Mark A. Horowitz Approved for the University Committee on Graduate Studies. iii Abstract Typical stereo displays stimulate incorrect focus cues because the light comes from a single surface. The consequences of incorrect focus cues include discomfort, difficulty perceiving the depth of stereo images, and incorrect perception of distance. This thesis describes a prototype stereo display comprising two independent volumetric displays. Each volumetric display is implemented with three image planes, which are fixed in position relative to the viewer, and are arranged so that the retinal image is the sum of light from three different focal distances. Scene geometry is rendered separately to the two fixed-viewpoint volumetric displays, using projections that are exact for each eye.
    [Show full text]
  • Computer Graphics: Principles and Practice
    Top: Courtesy of Michael Kass, Pixar Courtesy of Daniel Keefe, University of Minnesota. and Andrew Witkin, © 1991 ACM, Inc. Reprinted by permission. Bottom: Courtesy of Greg Turk, © 1991 ACM, Inc. Reprinted by permission. (0, 0, 0) (0, y9, 0) (0, y9, 1) (0, y, 0) (0, y, z) Courtesy of Steve Strassmann. © 1986 ACM, Inc. Reprinted by permission. Courtesy of Ken Perlin, © 1985 ACM, Inc. Reprinted by permission. Courtesy of Ramesh Raskar; © 2004 ACM, Inc. Reprinted by permission. Courtesy of Stephen Marschner, © 2002 ACM, Inc. Reprinted by permission. Courtesy of Seungyong Lee, © 2007 ACM, Inc. Reprinted by permission. Computer Graphics Third Edition This page intentionally left blank Computer Graphics Principles and Practice Third Edition JOHN F. HUGHES ANDRIES VAN DAM MORGAN MCGUIRE DAVID F. SKLAR JAMES D. FOLEY STEVEN K. FEINER KURT AKELEY Upper Saddle River, NJ • Boston • Indianapolis • San Francisco New York • Toronto • Montreal • London • Munich • Paris • Madrid Capetown • Sydney • Tokyo • Singapore • Mexico City Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests.
    [Show full text]
  • A Stereo Display Prototype with Multiple Focal Distances
    A Stereo Display Prototype with Multiple Focal Distances Kurt Akeley∗ Simon J. Watt† Ahna Reza Girshick† Martin S. Banks†† Stanford University∗ University of California, Berkeley† Abstract displays, which provide correct binocular disparity specifying a range of fixation distances while forcing accommodation to a single image plane. Typical stereo displays provide incorrect focus cues because the light comes from a single surface. We describe a prototype stereo The consequences of the forced decoupling of viewer vergence display comprising two independent fixed-viewpoint volumetric and accommodation include discomfort [Wopking¨ 1995], induced displays. Like autostereoscopic volumetric displays, fixed- binocular stress [Mon-Williams et al. 1993; Wann et al. 1995], viewpoint volumetric displays generate near-correct focus cues and difficulty in fusing the two images into a stereo pair [Wann without tracking eye position, because light comes from sources et al. 1995]. Another consequence of this decoupling is error at the correct focal distances. (In our prototype, from three image in the perception of scene geometry. Estimation of angles in planes at different physical distances.) Unlike autostereoscopic scene geometry is more accurate, for example, when correct volumetric displays, however, fixed-viewpoint volumetric displays focal distance information is provided than when correct binocular retain the qualities of modern projective graphics: view-dependent projections of an object are viewed at the wrong accommodative lighting effects such as occlusion, specularity, and reflection are distance [Watt et al. 2003]. Accommodation to a single image plane correctly depicted; modern graphics processor and 2-D display also eliminates a depth cue—variation in blur—and this too causes technology can be utilized; and realistic fields of view and depths error in the perception of scene geometry [Mather and Smith 2000].
    [Show full text]