EGGH98: SIGGRAPH/Eurographics Workshop on Graphics Hardware 1998

Permanent URI for this collection

https://diglib.eg.org/handle/10.2312/337

Browse

Browsing EGGH98: SIGGRAPH/Eurographics Workshop on Graphics Hardware 1998 by Subject "and texture"

Now showing 1 - 3 of 3
  • Thumbnail Image
    Item
    High-Quality Volume Rendering Using Texture Mapping Hardware
    (The Eurographics Association, 1998) Dachille, Frank; Kreeger, Kevin; Chen, Baoquan; Bitter, Ingmar; Kaufman, Arie; S. N. Spencer
    We present a method Jor volume rendering of regular grids which takes advantage of 3D texture mapping hardware currently, available on graphics workstations. Our method products accurate shading for arbitrary and dynamically changing directional lights, viewing parameters, and transfer functions. This is achieved by hardware interpolating the data values and gradients before software classification and shading. The method works equally well for parallel and perspective projections. We present two approaches for OUT method: one which takes advantage of software ray casting optimizations and another which takes advantage of hardware blending acceleration.
  • Thumbnail Image
    Item
    Neon: A Single-Chip 3D Workstation Graphics Accelerator
    (The Eurographics Association, 1998) McCormack, Joel; McNamara, Robert; Gianos, Christopher; Seiler, Larry; Jouppi, Norman P.; Correll, Ken; S. N. Spencer
    High-performance 3D graphics accelerators traditionally require multiple chips on multiple boards, including geometry, rasterizing, pixel processing, and texture mapping chips. These designs are often scalable: they can increase performance by using more chips. Scalability has obvious costs: a minimal configuration needs several chips, and some configurations must replicate texture maps. A less obvious cost is the almost irresistible temptation to replicate chips to increase performance, rather than to design individual chips for higher performance in the first place. In contrast, Neon is a single chip that performs like a multichip design. Neon accelerates OpenGL [19] 3D rendering, as well as X11 [20] and Windows/NT 2D rendering. Since our pin budget limited peak memory bandwidth, we designed Neon from the memory system upward in order to reduce bandwidth requirements. Neon has no special-purpose memories; its eight independent 32-bit memory controllers can access color buffers, 1. depth buffers, stencil buffers, and texture data. To fit our gate budget, we shared logic among different operations with similar implementation requirements, and left floating point calculations to Digital s Alpha CPUs. Neon s performance is between HP s Visualize fx<sup>4</sup> and fx<sup>6</sup>, and is well above SGI s MXE for most operations. Neon-based boards cost much less than these competitors, due to a small part count and use of commodity SDRAMs.
  • Thumbnail Image
    Item
    Texture Tile Visibility Determination For Dynamic Texture Loading
    (The Eurographics Association, 1998) Goss, Michael E.; Yuasa, Kei; S. N. Spencer
    Three-dimensional scenes have become an important form of content deliverable through the Internet. Standard formats such as Virtual Reality Modeling Language (VRML) make it possible to dynamically download complex scenes from a server directly to a web browser. However, limited bandwidth between servers and clients presents an obstacle to the availability of more complex scenes, since geometry and texture maps for a reasonably complex scene may take many minutes to transfer over a typical telephone modem link. This paper addresses one part of the bandwidth bottleneck, texture transmission. Current display methods transmit an entire texture to the client before it can be used for rendering. We present an alternative method which subdivides each texture into tiles, and dynamically determines on the client which tiles are visible to the user. Texture tiles are requested by the client in an order determined by the number of screen pixels affected by the texture tile, so that texture tiles which affect the greatest number of screen pixels are transmitted first. The client can render images during texture loading using tiles which have already been loaded. The tile visibility calculations take full account of occlusion and multiple texture image resolution levels, and are dynamically recalculated each time a new frame is rendered. We show how a few additions to the standard graphics hardware pipeline can add this capability without radical architecture changes, and with only moderate hardware cost. The addition of this capability makes it practical to use large textures even over relatively slow network connections.