To appear in the IEEE 2001 Symposium on Parallel and Large Data Visualization and Graphics proceedings
Jupiter: A Toolkit for Interactive Large Model Visualization Dirk Bartz, Dirk Staneker, Wolfgang Straßer Brian Cripe, Tom Gaskins, Kristann Orton WSI/GRIS, University of T¨ubingen, Germany Hewlett-Packard Company, Corvallis, OR, USA Michael Carter, Andreas Johannsen, Jeff Trom Engineering Animation Inc., Ames, IA, USA
Abstract The fast increasing size of datasets in scientific computing, mechanical engineering, or virtual medicine is quickly exceeding the graphics capabilities of modern computers. Toolkits for the large model visualization address this problem by combining efficient geometric techniques, such as occlusion and visibility culling, mesh reduction, and efficient rendering. In this paper, we introduce Jupiter, a toolkit for the interactive visualization of large models which exploits the above mentioned techniques. Jupiter was originally developed by Hewlett-Packard and EAI, and it was recently equipped with new functionality by the University of T¨ubingen, as being part of the Kelvin project. Earlier this year, an initial version of Jupiter was also released as open source. CR Categories: I.3.3 [Picture/Image Generation]: Viewing Algorithms, Occlusion Culling; I.3.4 [Graphics Utilities]: Application Packages, Graphics Packages; I.3.5 [Computational Geometry and Object Modeling]: Object Hierarchies; I.3.7 [Three-Dimensional Graphics and Realism]: Hidden Line/Surface Removal; Keywords: Large Model Visualization, Toolkit, Visibility and occlusion culling.
1 INTRODUCTION In recent years, Large Model Visualization (LMV) or Large Scale Data Visualization became one of the most important research fields in scientific computing. The reason of the emergence of LMV lies in the fast increasing size of datasets from various sources. Research efforts are mostly driven by simulation of natural phenomena (ie., global and regional weather, ocean dynamics, high energy and astro-physics, etc.), the increasing dataset size of medical scanners (ie., multi-slice Computer Tomography, rotational biplanar Xray) and design review tasks in product data management systems (PDM). The developed techniques focus on database management, architectural aspects of large computing systems, parallel computing, and last but not least, rendering techniques for the visualization of large models. Two issues are usually the major subject of large data handling; memory efficiency and rendering performance. However, many fbartz,dstaneke,
[email protected]
standard visualization techniques require substantial auxiliary data like spatial data-structures or distance fields which are usually computed in a pre-process. Storing this data can exceed the memory capacities of the visualization host computer, prompting the use of different visualization algorithms. Some visualization applications, ie. design review tasks or intra-operative navigation-based visualization in medicine, require a certain rendering performance to provide interactive or even real-time framerates, where an interactive framerate usually specifies more than ten frames-per-second (fps), and a real-time framerate more than 20 fps. Unfortunately, the data volume generated by applications in architecture, medicine, mechanical engineering, or scientific computing grows faster than the rapidly increasing graphics performance of modern graphics subsystems. This growing divide requires approaches which reduce the complexity by orders of magnitude. Several methods have been proposed in the recent years to address this divide. Among the most popular are mesh-reduction [12] and subdivision [34], visibility and occlusion culling [7], parallel processing [4], geometry compression [31], image-based rendering [9], and recently, point-based rendering [6, 21, 23]. Some of these techniques have been integrated in modern 3D rendering toolkits for large models, such as Jupiter. This paper is organized as follows; the next section briefly reviews related toolkits for visualization of large models. In Section 2, we introduce the Jupiter toolkit for large model visualization and present our extensions in Section 3. Finally, we summarize our results in Section 4.
1.1 Related Work Many research projects focussed on the visualization of large datasets. Some aim at a ray-based visualization [13, 20, 17, 32], others aim at a polygonal representation [30, 22, 14, 15]. Here, we concentrate on polygon-based visualization systems. Among the first systems is the OpenInventor toolkit [30, 33]. OpenInventor emphasized modeling and manipulation aspects which led to a rich functionality and a wide acceptance in the computer graphics community and became an open source project in 2000. Unfortunately, interactive rendering was not a major project goal of OpenInventor, which was complemented by the IRIS Performer toolkit [22] that focussed in particular on interactive rendering in multi-pipe and multi-processor environments. Concepts of IRIS Performer were later incorporated in SGI’s OpenGL Optimizer [15], a toolkit for the efficient rendering of large models. OpenGL Optimizer was built on top of the Cosmo3D scene graph API, which in turn was built on top of the OpenGL graphics API. It provided multi-processor support, view-frustum and occlusion culling (based on SGI’s histogram extension), and many other tools, similar to the toolsets provided by Jupiter, which was developed at the same time by Hewlett-Packard (HP) and Engineering Animation Inc. (EAI). This year, Jupiter became open source as part of the Kelvin project (see Section 2). The technology of Jupiter and OpenGL Optimizer was also planned to be part of the Fahrenheit project, which was started in late 1997 by HP, Microsoft, and SGI. With the departure of SGI from the Fahren-
To appear in the IEEE 2001 Symposium on Parallel and Large Data Visualization and Graphics proceedings JtNode
heit project in 1999, this project came to a virtual halt. The lack of a scene graph-based large model visualization Application Programming Interface (API) prompted in 2000 the start of the OpenSG project [10]. OpenSG is planned as an open source project with multi-processor support and a variety of geometric tools, such as simplification, subdivision, or culling. Other systems for large model visualization include the also open source Visualization Toolkit (VTK) [25], the Utah SCIRun project [19], the General Electric Galileo system [28], or the UNC walkthrough project [1].
JtPartition
JtGroup
JtShape
JtInstance
JtVertexShape
JtLOD JtRangeLOD
JtTriStripSet JtPolylineSet JtPolygonSet
Figure 1: Jupiter node class hierarchy
A scene graph in Jupiter is an acyclic directed graph. It consists of a variety of nodes (see Fig. 1) which describe the partition of the model into objects and groups of objects (see Fig. 2). Objects or group of objects can be instantiated by JtInstance, where individual transformation matrix of every node might specify a different 3D location. Furthermore, a group can provide the (group of) objects at different levels of details (JtLOD). Partitions of the
2 THE JUPITER TOOLKIT In this section, we describe Jupiter, a scene graph-based toolkit for the interactive visualization of large polygonal models [14]. Jupiter is based on a software initiative of Hewlett-Packard Company (HP) and Engineering Animation Inc. (EAI) which led early in 1997 to the large model toolkit Jupiter, formerly also known as DirectModel [8]. (The rights to the name “DirectModel” were later acquired by Microsoft.) This initiative was canceled later the same year, in favor of the Fahrenheit project of HP, Microsoft, and SGI, which included the development of API layers for scene graphbased rendering (Fahrenheit Scene Graph) and for the visualization of large models (Fahrenheit Large Model). EAI continued working on Jupiter. With the virtual halt of the Fahrenheit project in 1999, Jupiter was re-launched by HP as the OpenSource project Kelvin in collaboration with the WSI/GRIS of the University of T¨ubingen [29]. The two main goals of the Kelvin project were the port of Jupiter to PC-based Linux, and the development and implementation of advanced occlusion culling mechanisms, into Jupiter. The source code of Jupiter is now available for download from http://www.gris.uni-tuebingen.de/kelvin. Originally, Jupiter was developed as platform and graphics API independent toolkit, available with support for OpenGL, Direct3D, and StarBase on Windows and UNIX systems. In the current version, Jupiter is limited to OpenGL and in the first releases to UNIX systems (Linux, HP-UX, IRIX1 ).
2.1 Jupiter Scene Graph Models are represented in Jupiter as logical graphs which describe a hierarchical organization of the objects of the model. Essentially, this logical graph is nothing else than a scene graph of the model. Therefore, we will only use the term scene graph in the course of this paper. These hierarchical representation can be generated from a model database (ie., from an assembly part list of a MCAD product data management system), from architectural drawings, from regular subdivision schemes (such as BSP-trees [11], octrees [24], or k-d trees [5]), or they are generated from a “soup” of polygons by a variety of different methods [18]. The scene graph can also contain different levels of detail to allow the rendering at different fidelity levels to account for the available rendering resources. In contrast to OpenInventor-like scene graphs [30], nodes inherit attributes only top-down (from parent nodes to child nodes), but not from the left to the right (through sibling nodes). This enables the parallel evaluation of subtrees of the scene graph, which is planned for later versions of Jupiter.
Figure 2: Jupiter scene graph of a wheel from the Formula One model (see also Fig. 3).
model (JtPartition) specify subtrees of the scene graph which can be dynamically swapped to disc, if they are evaluated having a low priority, or restored from disc otherwise. This swapping mechanism is provided by the residency request manager of Jupiter, to accommodate for situations, where the model does not fit into the available memory (see Fig. 5). Figure 2 shows the scene graph of a wheel from the Formula One model (see also Fig. 3). It contains three different levels of details, wrapped in partition nodes.
1 Note that some of the occlusion culling functionality uses the HP occlusion culling flag (HP occlusion flag) [26], which is only available on the HP Visualize FX series of graphics subsystems. Consequently, the related functionality is neither available on Linux systems with other graphics subsystems (until similar functionality become available), nor on IRIX systems. However, this is going to change in the future; nVIDIA has already announced occlusion culling support similar to the HP occlusion culling flag for the new GeForce3 graphics card.
2.2 Scene Graph Traversal in Jupiter The scene graph traversal in Jupiter is managed by strategies that decide which node of the scene graph is rendered, depending on a specified budget2 . Each strategy consists of a set of pipelined 2 Variations
on budget oriented rendering were also presented in 1999 by Bartz et al. [3] and later by Klosowski and Silva [16].
2
To appear in the IEEE 2001 Symposium on Parallel and Large Data Visualization and Graphics proceedings agents which evaluate the importance of the scene graph nodes and manipulate the traversal order accordingly. The importance can be based on the visibility of the node, on its visual contribution, or on specific properties of a node. The agents are called in a pipelined fashion, where the following agent processes the resulting scene graph from the previous agent. The order of this pipeline also determines their performance; agents which have low associated costs should be executed before agents with high costs, since the number of nodes evaluated by the expensive agents can be significantly reduced this way. The result of an applied strategy is a render list of geometry nodes that are passed to the render context for rendering. This list is also handled by an agent. Jupiter provides agents for several purposes; the residency request agent (JtResReqAgent) request nodes of the scene graph to be loaded by the residency request manager, or releases nodes which are no longer needed. If objects need to be omitted from rendering, the respective nodes can be filtered by the property key filter agent (JtPropKeyFilterAgent). The selection of nodes by mouse clicks (“picking”) is calculated by ray intersections from the view point with the pick agent (JtPickAgent).
Figure 4: Formula One model; all bright interior bounding boxes are determined as occluded. Applikation redraw()
Jupiter JtView render() execute() JtResidencyRequestManager
willNeed()
apply() JtStrategy applyAt()
beginIteration()
Figure 3: Three different level of detail nodes of a wheel from the Formula One model. The left full detailed wheel contains 21K triangles, the middle medium level of detail contains 10K triangles, and the right lower level of detail contains 6K triangles.
JtAgent* JtVFCAgent ... JtResReqAgent ... JtRenderAgent
performActions() JtNodeIter visitNode() selectChild()
endIteration()
The standard traversal scheme of Jupiter traverses the scene graph in a depth-first order using a stack-based iterator. However, a different traversal scheme is usually chosen by the priority driven heap iterator of value node selector (JtValueNodeSelectAgent). This agent computes this priority based on the screen coverage of the bounding sphere, and selects a respective level of detail if provided in the scene graph. The larger the estimate of the screen coverage of the node is, the higher level of detail is selected (see Fig. 3). In contrast, the range level of detail agent (JtRangeLODAgent) selects the level of detail based on the distance between the view point and the center of the bounding box of the node. A fixed level of detail can be chosen by the agent JtFixedARAgent. Another important family of agents are the culling agents. The culling agent with the smallest test costs and no visual degradation is the view frustum culling agent (JtViewFrustumCullAgent) which removes nodes from the render list, if they do not intersect with the view frustum, thus being not visible. Nodes can also be culled based on their estimated screen coverage by the screen size cull agent (JtScreenSizeCullAgent), which is also an agent test with low associated costs. Another most effective culling agent is the occlusion culling agent (JtOcclusionAgent). By using the HP occlusion culling flag [26] of the HP Visualize FX graphics subsystems, this agent removes nodes when their bounding box is not visible (see Fig. 4). At the moment, this agent is disabled in the used strategy on all other graphics subsystems. Two rendering agents are available which stream the selected geometry from the scene graph to the graphics API. The render agent (JtRenderAgent) passes every node which is traversed by the agent to the render context. In contrast, the render list agent (JtRenderListAgent) collects all relevant nodes in a render list. After the traversal of all agents of the scene graph, this render list is passed
Figure 5: A strategy calls a set of pipelined agents which process the scene graph.
to the render context for a highly optimized rendering. Figure 5 shows a typical sequence of agents applied by a strategy to a scene graph. For every redraw-event of the application, the render action applies the strategy, which in turn calls the enabled agents. Each agent traverses the scene graph to evaluate the specific priority of the nodes. If the current node is not available, it is requested by the JtResReqAgent from the Residency Request Manager which restores (or swaps) the respective nodes. Finally, all remaining nodes are rendered by the render agent.
2.3 Tools Jupiter implements a rich variety of tools which can be used by an application. These tools can be used to process and filter models in order to improve interactivity or rendering quality. The tessellator class of tools replaces higher-level primitives into optimized representations. Jupiter provides three different tessellator tools; the triangulator tessellates general polygons into individual triangles. Individual triangles can be converted into triangle strips by the tri-stripper tool. Finally, the surface tessellator evaluates trimmed NURBS-surfaces and generates a single triangle strips
3
To appear in the IEEE 2001 Symposium on Parallel and Large Data Visualization and Graphics proceedings model
for each surface. The simplifier tools generate a simpler representation of a subtree of the scene graph. The offered quality levels range from simply removing all of the geometry to vertex elimination or edge collapse based algorithms. Other simplifiers generate bounding volume geometry from the node geometry, such as bounding boxes or convex hulls.
Boom Box Formula One Cotton Picker
depth sorted [%] [fps] 71.4 12.6 71.1 7.1 64.8 1.46
screen coverage [%] [fps] 33.4 5.3 38.8 4.8 41.1 0.4
hit rate [%] 99.8 99.7 99.6
Table 2: Occluded nodes and resulting framerates of depth sorted or screen coverage based traversal priority.
3 THE KELVIN PROJECT The major goals of the Kelvin project were the adaption of the HPUX version of Jupiter to the Linux operating system and the integration of more advanced culling techniques into Jupiter. In this section, we describe how we achieved these project goals.
The Linux port of Jupiter was straight forward. We based the Linux version on the Red Hat distribution 6.2, which was the HP recommended distribution at the time. Initial template declaration problems were due to the old gcc compiler version available in Red Hat’s 6.2 distribution. After replacing the old 2.91.2 version with the gcc version 2.95.2, the template problems worked out smoothly. Note that the currently distributed pre-release gcc version 2.96 also introduces similar compiler problems.
the screen size driven traversal, which in turn results in an 50% to 300% framerate increase. These results are not really surprising, since depth sorting is a standard technique of occlusion culling approaches. The lack of a depth sorting driven priority is due to the late implementation of the occlusion culling agent JtOcclusionAgent into the original version of Jupiter. In the fourth column of Table 2, we show the hit rate of the depth sorted occlusion tests. To calculate this rate, we render the full model without any occlusion culling. Thereafter, the view-frustum and occlusion culling agents traverse the scene graph to estimate the full occlusion potential of all nodes against the rendered model. As it turns out, more than 99.5% of this potential in the investigated MCAD models is correctly estimated with depth sorted occlusion culling, which shows the high efficiency of this traversal scheme.
3.2 Occlusion and Visibility Culling
3.2.2 Redundant Model Nodes
Jupiter already provides a set of efficient culling agents. As already mentioned in Section 2.2, these agents include view-frustum culling, bounding-box based occlusion culling using the HP flag [26], and a screen space size sensitive culling. We supplement the available culling agents by a set of new techniques which also exploit new culling features provided by the HP Visualize FX series of graphics subsystems. We base the performance measurements on a set of reasonable large polygonal models from mechanical engineering. These models are described in Table 1. Other examples can be found in Figure 6. All measurements were performed on a HP P-class PC with two PIII @ 750MHz (using only one CPU), 768 MB main memory, and a HP Visualize FX10 graphics subsystem.
Models from MCAD PDM systems are provided in a hierarchical assembly part list which describes how individual objects are composed into higher level entities. In this modeling process, several hierarchy elements are introduced which cluster relevant information. However, this process leads also to inner nodes with only one child node. We call these nodes redundant nodes, since the result of the occlusion test of the redundant node is the same as the result of the occlusion test of the child node, which classifies the first test as redundant. Example of these redundant nodes can be seen in the scene graph of the Formula One wheel in Figure 2.
3.1 Linux Version of Jupiter
model Boom Box Formula One Cotton Picker
#triangles 644,268 746,827 10,978,050
#objects 530 306 13,270
model Boom Box Formula One Cotton Picker
depth 13 8 12
total #nodes 5,069 3,364 78,020
#red’ nodes 1,004 906 24,879
reduction [%] 20 26 32
Table 3: Total number of scene graph nodes and the number of redundant nodes in the models, as well as the accomplished scene graph reduction.
Table 1: Model complexity overview: The number of triangles and objects, and the depth of the scene graph for each model are listed.
In the new version of Jupiter, no occlusion tests are performed on redundant nodes. Table 3 shows how many nodes in the scene graph of a model are redundant. Note that not all redundant nodes are visited, since many of them are already culled if one of their parent nodes is already occluded. Therefore, only visible redundant nodes increase the overall occlusion costs. Overall, skipping of potentially visible redundant nodes achieves an increase of the framerate of approximately 50%.
3.2.1 Depth Sorting Jupiter provides two different scene graph traversal methods; a depth-first order scheme, and the screen-coverage-based scheme of the value node selector agent. While the later traversal technique provides a good heuristic for the selection of an appropriate level of details, it is significantly less suited for occlusion culling. Therefore, we implemented a variation of the priority driven heap iterator. In contrast to the screen coverage criterion, this priority is driven by the depth value of the front-most bounding box vertex of the current node. Table 2 shows the results for the two different traversal schemes. On average, depth sorting removes up twice as much geometry as
3.2.3 Multiple Occlusion Queries One of the problems of HP flag like occlusion culling approaches is the required graphics pipeline flush to collect the result of the queries. This flush can represent a significant bottleneck, if the number of occlusion queries increases drastically with the smaller
4
To appear in the IEEE 2001 Symposium on Parallel and Large Data Visualization and Graphics proceedings amount of geometry for each object to be tested. Severson accounted the costs for one occlusion test with the equivalent of the rendering of 190 triangles of the average size of 25 pixels [27]. The HP Visualize FX graphics subsystems allows the pipelined occlusion query of multiple objects without waiting for the result of the previous object. This also means that the occlusion potential of the multiple objects is not taken into account for the succeeding tests. If we assume a depth sorted order of the nodes, most of the farthest nodes will not contribute much to the occlusion of the other nodes, since they are already occluded by the closer nodes. In this case, the multiple occlusion queries of the farthest objects can save occlusion test overhead. In Jupiter, we integrated the multiple occlusion queries in an updated occlusion culling agent for nodes which are located in the backward space of the view-frustum. Furthermore, we applied the multiple occlusion queries only to leaf nodes of the scene graph, since inner nodes have a significantly larger influence on the visibility information than leaf nodes. It turned out that an efficient use multiple occlusion queries is quite difficult to achieve. MCAD models frequently have a hierarchical representation which enables culling of occluded inner nodes, which reduces the number of not yet occluded leaf nodes in the back space of the view-frustum significantly. All achieved performance gain due to less synchronization costs were used up quickly, if the multiple occlusion queries generated a false positive occlusion response. Even a wrongly as not occluded classified leaf node of only 1000 triangles outweighs the costs of four to five regular occlusion culling tests. However, multiple occlusion queries improve their effectiveness with different traversal techniques; if the occlusion culling agent visits only the depth sorted leaf nodes of the scene graph, more nodes with a high occlusion likelihood can be passed through the multiple occlusion queries to the graphics subsystem. Traversal techniques which exploit time-coherence heuristics might also increase the efficiency of multiple occlusion queries, and benefit from the reduced occlusion culling overhead.
new occlusion culling and traversal techniques are expected to be released in the second quarter of this year. Future work will focus on the adaption of the Jupiter occlusion culling agents to other graphics subsystems (ie., nVIDIA GeForce3). Other topics include further quantitative occlusion culling techniques using features that are available on the current generation of HP Visualize FX5 and FX10, such as the visibility statistics extension, and a more efficient use of multiple occlusion queries. Another major topic for future work is support for multiple graphics pipelines and multiple processors. Some of the project goals will probably be managed as open source projects.
ACKNOWLEDGEMENTS This work is supported by Kelvin – the Large Model Visualization project of the Workstations Systems Lab, Ft. Collins, CO of the Hewlett-Packard Company and by DFG project CatTrain. The MCAD datasets are courtesy of Engineering Animation Inc. and Hewlett-Packard Company; the bluntfin dataset is courtesy of NASA Ames, and the skull dataset is courtesy of Siemens Medical Systems, Forchheim. Mike Bialek, Brian Cripe, Tom Gaskins, Dan Olsen, Kristann Orton, Andrew Page, Joe Whitty, and Pieter van Zee of HP, and Michael Carter, Brett Harper, Andreas Johannsen, Scott Nations, Sebastian Marino, Helder Pinheiro, Ralph Pinheiro, Adrian Sannier, Jeff Trom, and Samir Uppal of EAI were the members of the original Jupiter development team. We would like to thank Andrew Page of HP Labs, Palo Alto, CA, Alan Ward and Bruce Blaho of HP’s Workstations Systems Lab, Ft. Collins, CO, and Michel Benard of HP Europe for their support and help pursuing the Kelvin project, and Michael Meißner of the University of T¨ubingen for proof reading.
References [1] D. Aliaga, J. Cohen, A. Wilsonand E. Baker, H. Zhang, C. Erikson, K Hoff, T. Hudson, W. St¨urzlinger, R. Bastos, M. Whitton, F. Brooks, and D. Manocha. MMR: An Integrated Massive Model Rendering System Using Geometric and Image-Based Acceleration . In Proc. of ACM Symposium on Interactive 3D Graphics, 1999.
3.2.4 General Bounding Volumes The original version of Jupiter allows only bounding boxes as bounding volumes for occlusion culling. These bounding boxes do frequently include a much larger object space and screen area, once rasterized into screen space, than the actual geometry. That effect can lead to false positive occlusion tests. These false positive occlusion tests can be reduced if tighter bounding volumes are used. Early experiments with the three MCAD models exhibit an additional 10% occlusion potential, if the actual node geometry is used for the occlusion test, in contrast to the bounding box [2]. Note that this potential can be even larger, if rather irregular shaped objects need to be visualized. In the Kelvin based version of Jupiter, arbitrary bounding volumes can be used, if they are provided as a list of triangles. These bounding volumes can be generated by the Jupiter tools, such as the convex hull simplifier, or other simplified versions of the original geometry, as long as they completely contain the original geometry of the node.
[2] D. Bartz, J. Klosowski, and D. Stanekerßer. k-DOPs as Tighter Bounding Volumes for Better Occlusion Performance. In Visual Proc. of ACM SIGGRAPH, 2001. [3] D. Bartz, M. Meißner, and T. H¨uttner. OpenGL-assisted Occlusion Culling of Large Polygonal Models. Computers & Graphics, 23(5):667–679, 1999. [4] D. Bartz, C. Silva, and B. Schneider. Rendering and Visualization in Parallel Environments. In ACM SIGGRAPH Course 13, 2000. [5] J. Bentley. Multidimensional Binary Search Trees Used for Associative Search. Communications of the ACM, 18(9):509– 516, 1975.
4 CONCLUSIONS and FUTURE WORK
[6] H. Cline, W. Lorensen, S. Ludke, C. Crawford, and B. Teeter. Two Algorithms for the Three-Dimensional Construction of Tomograms. Medical Physics, 15(3)(3):320–327, 1988.
In this paper, we introduced Jupiter, a toolkit for the interactive visualization of large models. Jupiter provides a rich set of techniques to achieve the requested framerate, including techniques for multi-resolution and geometry culling. The Linux version of Jupiter is currently available for download as open source from http://www.gris.uni-tuebingen.de/kelvin. The
[7] D. Cohen-Or, Y. Chrysanthou, F. Durand, and C. Silva. Visibility: Problems, Techniques, and Application. In ACM SIGGRAPH Course 4, 2000.
5
To appear in the IEEE 2001 Symposium on Parallel and Large Data Visualization and Graphics proceedings [8] B. Cripe and T. Gaskins. The DirectModel Toolkit: Meeting the 3D Graphics Needs of Technical Applications. The Hewlett-Packard Journal, (May):19–27, 1998.
[27] K. Severson. VISUALIZE fx Graphics Accelerator Hardware. Technical report, Hewlett Packard Company, available from http://www.hp.com/workstations/support/documentation/ whitepapers.html, 1999.
[9] P. Debevec, C. Bregler, M. Cohen, R. Szeliski, L. McMillan, and F. Sillion. Image-Based Modeling, Rendering, and Lighting. In ACM SIGGRAPH Course 35, 2000.
[28] L. Sobierajski-Avila and W. Schroeder. Interactive Visualization of Aircraft and Power Generation Engines. In Proc. of IEEE Visualization, pages 483–486, 1997.
[10] OpenSG Forum. OpenSG - Open Source Scenegraph. http://www.opensg.org, 2000.
[29] D. Staneker. Ein hybrider Ansatz zur effizienten Verdeckungsrechnung. Master’s thesis, Dept. of Computer Science (WSI), University of T¨ubingen, 2001.
[11] H. Fuchs, Z. Kedem, and B. Naylor. On Visible Surface Generation by a Priori Tree Structures. In Proc. of ACM SIGGRAPH, pages 124–133, 1980.
[30] P. Strauss and Carey R. An Object-oriented 3D Graphics Toolkit. In Proc. of ACM SIGGRAPH, pages 341–349, 1992.
[12] M. Garland. Multiresolution Modeling: Survey and Future Opportunities. In Eurographics STAR report 2, 1999.
[31] G. Taubin. 3D Geometry Compression and Progressive Transmission. In Eurographics STAR report 3, 1999.
[13] R. Grzeszczuk, C. Henn, and R. Yagel. Advanced Geometric Techniques for Ray Casting Volumes. In ACM SIGGRAPH Course 4, 1998.
[32] I. Wald, P. Slusallek, C. Benthin, and M. Wagner. Interactive Rendering with Coherent Ray Tracing. In Proc. of Eurographics, 2001.
[14] Hewlett-Packard. Jupiter 1.0 Specification. Technical report, Hewlett Packard Company, Corvallis, OR, 1998.
[33] J. Wernecke. The Inventor Mentor. Addison Wesley, Reading, Mass., 1994.
[15] Silicon Graphics Inc. OpenGL Optimizer Programmer’s Guide. Technical report, 1998.
[34] D. Zorin, P. Schr¨oder, T. DeRose, L. Kobbelt, A. Levin, and W. Sweldens. Subdivision for Modeling and Animation. In ACM SIGGRAPH Course 23, 2000.
[16] J. Klosowski and C. Silva. Rendering on a Budget. In Proc. of IEEE Visualization, pages 155–122, 1999. [17] G. Knittel. The ULTRAVIS System. In Proc. of Symposium on Volume Visualization and Graphics, pages 71–80, 2000. [18] M. Meißner, D. Bartz, T. H¨uttner, G. M¨uller, and J. Einighammer. Generation of Subdivision Hierarchies for Efficient Occlusion Culling of Large Polygonal Models. Technical Report WSI-99-13, ISSN 0946-3852, Dept. of Computer Science (WSI), University of T¨ubingen, 1999. [19] S. Parker and C. Johnson. SCIRun: A Scientific Programming Environment for Computational Steering. In Proc. of Supercomputing, 1995. [20] S. Parker, P. Shirley, Y. Livnat, C. Hansen, and P. Sloan. Interactive Ray Tracing for Isosurface Rendering. In Proc. of IEEE Visualization, pages 233–238, 1998. [21] H. Pfister, M. Zwicker, J. Baar, and M. Gross. Surfels: Surface Elements as Rendering Primitives. In Proc. of ACM SIGGRAPH, pages 335–342, 2000. [22] J. Rohlf and J. Helman. IRIS Performer: A High Performance Multiprocessing Toolkit for Real-Time 3D Graphics. In Proc. of ACM SIGGRAPH, pages 381–394, 1994. [23] S. Rusinkiewicz and M. Levoy. Qsplats: A Multiresolution Point Rendering System for Large Meshes. In Proc. of ACM SIGGRAPH, pages 343–352, 2000. [24] H. Samet. The Design and Analysis of Spatial Data Structures. Addison-Wesley, Reading, 1994. [25] W. Schroeder, K. Martin, and B. Lorensen. The Visualization Toolkit. Prentice Hall, Upper Saddle River, NJ, 2nd edition, 1998. [26] N. Scott, D. Olsen, and E. Gannett. An Overview of the VISUALIZE fx Graphics Accelerator Hardware. The HewlettPackard Journal, (May):28–34, 1998.
6
To appear in the IEEE 2001 Symposium on Parallel and Large Data Visualization and Graphics proceedings
(a)
(b)
(c)
(d)
(e)
Figure 6: Rendering of models from MCAD, medicine, and scientific computing: (a) Boom Box - cover parts are removed on the right side of the clipping plane; (b) Cotton Picker model; (c) Skull reconstructed from a rotational biplane X-ray volume dataset; (d) Vortex breakdown of a fluid injection into another fluid; (e) Blunt Fin: Density is used as an isovalue, while the kinetic energy is mapped as color onto the isosurface.
7
