Multi-User View-Dependent Rendering

Multi-User View-Dependent Rendering Jihad El-Sana Department of Computer Science Ben-Gurion University Beer-Sheva, 84105, Israel [email protected]

Abstract In this paper we are presenting a novel architecture which allows rendering of large-shared dataset at interactive rates on an inexpensive workstation. The idea is based on view-dependent rendering on a client-server network. The server stores the large dataset and manages the selection of the various levels of detail while the inexpensive clients receive a stream of update operations that generate the appropriate level of detail in an incremental fashion. These update operations are based on changes in the clients’ view-parameters. Our approach dramatically reduces the amount of memory needed by each client and the entire computing system since the dataset is stored only once on the server’s local memory. In addition, it decreases the load on the network as results of the incremental update contributed by view-dependent rendering.

1

Introduction

The advances in three-dimensional acquisition, simulation, and design technologies enable the generation of complex polygonal models and large virtual environments. However, most of these datasets exceed the main memory size and the interactive rendering capabilities of current graphics hardware resulting in unacceptable frame rates for most applications that require real-time interaction. Several software and algorithmic solutions have been recently proposed to bridge the increasing gap between hardware capabilities and the complexity of the graphics datasets. These include level-of-detail rendering, occlusion culling, and image-based rendering. Recently view-dependent rendering has been introduced to enable seamless and adaptive level-of-detail representations on real-time for polygonal datasets. The level of detail selection is based on view parameters such as view location, illumination, and speed of motion. Current view-dependent rendering schemes usually increase the size of the dataset, require the existence of the entire dataset in main memory, and do not enable different users to share the dataset currently in memory. To overcome the memory size drawback El-Sana and Chiang [8] have developed an external memory view-dependent simplification. However, their approach provides only a single-user solution and requires an additional level of preprocessing. In an era of reasonably fast communication networks and supercomputer servers with large memory size, the issue of sharing the multiresolution representation of the dataset becomes even more crucial. To clarify this issue let us consider, as an example, a large CAD firm. In such a firm, usually there are several engineers who work on the same product which is generally very large, complex, and therefore kept on a local server. Often, these

users can not bring the entire model to their local workstations because either the entire model exceeds their local machines’ memories or they must keep consistency on the model database. In addition, sending the entire dataset to the users’ machines at each frame or even every dozen frames would overwhelm the local network. Providing each user with a powerful workstation (in terms of computation, rendering capabilities, and memory size) seems to be an inadequate solution because it is too expensive and still does not handle all large datasets. Hence, we assume that users have inexpensive machines, which do not have the capability to render the entire dataset at interactive rates. The engineers, in our example, are interested in visualizing the entire dataset as well as observing small regions. For example, in a car design they are interested in the external appearance of the car – hence they have to visualize the entire car model– as well as observe the fitness of small fuel pipes. Using a lower resolution will allow rendering the entire model at interactive rates, even though its size exceeds that of the local memory and are beyond the rendering capability of the user’s workstation. Also, keeping the close-to-viewer, front-facing, and in-frustum regions at high resolution and far-form-viewer, back-facing, and off-frustum regions at low-resolution will enable visualizing the given dataset at interactive rates. Therefore, using view-dependent rendering seems to provide an excellent solution but the users’ machines often do not have the capability to carry out a view-dependent rendering procedure. Actually, this is the main motivation for combining multi-user visualization with view-dependent rendering. In this paper we have developed a view-dependent rendering for large datasets over a local network. Our solution is based on the view-dependent tree data-structure [10] and a client-server architecture. The view-dependence tree resides in a capable machine in terms of memory size and computation power. We shall refer to the capable machine as a server and to the other workstations as clients. During a connection session between a server and a client, the server receives the client’s viewparameters, then based on these parameters the server sends a list of operations which includes a set of vertices and triangles to insert or remove. On receiving these operations the client updates its display lists and sends them to its graphics hardware. Our architecture enables inexpensive workstations to take advantage of view-dependent rendering when visualizing large datasets. In addition, it reduces the memory needed by each client machine, improves the rendering frame rates, and dramatically reduces the communication load. Currently our approach works on local networks but we believe it should also work for geographically distributed networks. In the rest of the paper we shall first discuss previous work on multiresolution hierarchies and distributed rendering. Then we describe our approach followed by implementation details

and empirical results. Finally we draw some conclusions and suggest directions for future work. Client

Client

[9] have developed Skip Strip: a data-structure that efficiently maintains triangle strips during view-dependent rendering.

Client

2.2 View-Dependence Trees

Client

Client

Server

View-dependence tree [10] is a compact multiresolution hierarchical data-structure that supports view-dependent rendering. In fact, for a given input dataset the view-dependence tree construction often leads to a forest (set of trees) since not all the nodes can be merged together to form one tree. Viewdependence trees are constructed bottom-up by recursively applying the vertex-pair collapse operation (see figure 2). The order of the collapses is determined by a predefined simplification metric. Split

Figure 1: Server-Client network design.

d

d

i

c

e Na

Nb

g

e

a

2

Previous Work

Our system is based on two main ideas: view-dependent rendering and a set of users who share the visualized dataset. Next, we will briefly discuss some of the previous work in these two fields.

b

f

i

h

b

h

g

Np f

Collapse

(a)

(a)

Figure 2: Vertex-pair collapse and vertex split operations. The two nodes Na and Nb merge to create the parent node Np .

2.1 View-Dependent Rendering Most of the previous work on generating multiresolution hierarchies for level-of-detail-based rendering has concentrated on computing a fixed set of view-independent levels of detail. At runtime an appropriate level of detail is selected based on viewing parameters. Recent advances to address some of these issues in a view-dependent manner take advantage of temporal coherence to adaptively refine or simplify the polygonal environment from one frame to the next. In particular, adaptive levels of detail have been used in terrains by Gross et al [12] and Lindstrom et al [18]. Gross et al define wavelet space filters that allow changes to the quality of the surface approximations in locally-defined regions. Lindstrom et al define a quadtreebased block data structure that provides a continuous level of detail representation. Most of the work for view-dependent simplifications for general polygonal models is closely related to the concept of progressive meshes that are summarized next. Progressive meshes have been introduced by Hoppe [14] to provide a continuous resolution representation of polygonal meshes. Progressive meshes are based upon two fundamental operators –edge collapse and its dual, the vertex split. Merge trees have been introduced by Xia et al[27] as a datastructure built upon progressive meshes to enable real-time view-dependent rendering of an object. Hoppe [15] has developed a view-dependent simplification algorithm that works with progressive meshes. This algorithm proceeds to construct a vertex hierarchy over a progressive mesh in a top-down fashion by minimizing an energy function. Luebke and Erikson [19] define a tight octree over the vertices of the given model to generate hierarchical view-dependent simplifications. Gueziec et al [13] demonstrate a surface partition scheme for a progressive encoding scheme for surfaces in the form of a directed acyclic graph (DAG). Klein et al [16] have developed an illumination-dependent refinement algorithm for multiresolution meshes. Schilling and Klein [24] have introduced a refinement algorithm that is texture dependent. El-Sana et al

Split

Np

Np

Na

Na

Nb

CAT:{a,b,c,d,e} PAT:{a:0, c:2}

(a)

CAT:{a,f,g,h,i,c} PAT:{a:0,

SI

CAT:{b,d,e, f,g,h,i}

Collapse

PAT:{a:0,

Nb c:2}

PAT:{a:0,

c:5}

c:5}

(b)

Figure 3: The collapse and split operations on the viewdependent trees for the mesh in Figure 2. View-dependence trees are able to adapt to various levels of detail. Coarse details are associated with nodes that are close to the top of the tree (roots) and high details are associated with nodes that are close to the bottom of the tree (leaves). To be able to handle non-manifold cases, a more general scheme is used so that when a vertex split occurs more than two new adjacent triangles can be added that share the newly created edge (in the case of a manifold each edge is shared by no more than two triangles). The reconstruction of a real-time adaptive mesh requires the determination of the list of vertices of this adaptive mesh and the list of triangles that connect these vertices. Following [10], we refer to these lists as the list of active nodes and the list of active triangles. At each frame the active nodes list is traversed to adapt to the appropriate level-of-detail representation of the given scene. Figure 3 shows the split and merge operations in the view-dependent tree. The two active nodes Na and Nb in Figure 3(a) merge to make the node Np active (in Figure 3(b)). Note that CAT stands for Current Adjacent Triangles and PAT for Permanent Adjacent Triangles (see [10] for more detail).

In order to prevent foldover at run-time view-dependence trees use an implicit dependencies instead of storing explicit dependencies lists (as in [27] and [15]). Hence, they reduce the memory space to store the dependencies and require only local accesses. Implicit dependencies rely on the enumeration of vertices generated after each collapse during the construction of the view-dependence trees. If the model has n vertices at the highest level of detail they are assigned vertex-ids 0; 1; : : : ; n 1. Every time a vertex pair is collapsed to generate a new vertex, the id of the new vertex is assigned to be one more than the greatest vertex-id thus far. This process is continued till the entire view-dependence trees have been constructed.

2.3 Multi-User Interaction Several distributed systems have been developed to take advantage of the computing capabilities of the Internet such as ATLAS[2], Charlotte[3], JavaParty[22], and Legion[17]. These systems usually experiment with general-purpose applications while taking into account the characterization of current Internet access such as low bandwidth communication and high latency. Experimental distributed systems have also been developed for real-time iteration in shared virtual environments. The WAVE system[23] uses message managers to mediate communication between hosts. These message managers often manage to cull irrelevant messages. DEDICATED[11] is a distributed heterogeneous multimedia learning environment based on device-independent architecture. VEOS[6] is a distributed virtual environment which maintains consistency among all workstations by sending point-to-point messages. Anupam and Bajaj[1] have developed the Shastra, an extensible and programmable system that supports large scale, geographically dispersed collaboration amongst multi-users environment. NPSNET[20] uses a broadcast approach to maintain a large distributed battle field simulation over the Internet. Cspary[21] developers focus on providing a small group of scientists the means of interactive collaboration and data sharing. The RING system[26] manages large simulations by sending entity-state-change messages to one server who is responsible to redirect them to the users affected by the change. It has been used for visibility-based message culling during large simulations. DIVE[7] is a fully distributed heterogeneous virtual reality system, where users can navigate and interact in 3D space. Distributed multi-user virtual environment systems maintain consistency among the n workstation by sending messages to each other whenever any entity on the distributed environment changes its state. Various message exchange policies have been developed. Next we shall state some of these strategies







The workstation hosts the changed entity sends point-topoint messages to the n 1 other workstations. This approach generates a large number of messages, where most of them are not necessary. Among the systems use this policy were Build For Two [4] and VEOS [6] The workstation broadcasts the change to all the workstation on the network. This approach reduces the number of sent messages, yet many workstations have to process unnecessary messages. NPSNET [20], and VERN [5] have adopted this strategy Messages are sent to an intermediate server who is responsible to redirect them to the appropriate workstations.

The RING [26] and WAVE [23] systems have used similar policy.

3

Our Approach

Our approach provides a novel solution, which allows multiusers with inexpensive workstations to visualize large datasets. The users’ workstations usually lack the memory size and the rendering capability to interact (at interactive rates) with the large dataset by themselves. Our algorithm is based on clientserver communication network and view-dependent rendering. In our current implementation, we assume that the large dataset resides in a local server, which has enough memory and computation power to store and handle the entire multiresolution representation. Our system consists of a server application which runs on the server machine and several client applications that run on the clients’ inexpensive workstations. We shall refer to the server’s application as server and to the client’s application as client. Clients access the large dataset through the server machine without downloading the entire dataset into their local machines’ memory because of memory size, consistency, or security reasons. Since many users access the same dataset in the same server concurrently, our approach also aims to reduce the load on the local network to avoid undesirable slowdown. Next we shall describe the architecture of our system.

4

System Architecture

In this section we shall review the architecture of our system, which is based on one server and multiple clients (note that several servers could be running on the same local network). Therefore, we shall review the architecture of the server and client independently, and then we explain the shared aspects.

4.1 Server The server consists of two main entities, a server manager and a set of interfaces. The server manager is the main process of the server. It sets the public communication channel, initializes the shared memory arena, and loads the view-dependence tree of the given dataset into the shared memory. The server manager also listens on the public channel for requests for connection by new clients. For each calling client, the server creates an interface, which is responsible for the interaction with the calling client. Since the calling client and the created interface are associated with each other we shall refer to the calling client as the associate client and to the created interface as the associate interface. The interface stores the characteristic parameters of the associate client, maintains the active-nodes list of its associate client, and handles the client’s view-parameters changes. On each change of the client’s view-parameters, its associate interface updates the active-nodes list to adapt to a better representation of the viewed scene. The interface is also responsible for packing the merge/split operation and sending them with the proper additional information (such as new vertex coordinate and new triangles vertices) to its associate client. In order to deliver the appropriate level of detail, the interface periodically checks the data channel for changes in the view parameters such as camera position, view direction, and illumination. Then based on the updated view-parameters, it

Public Channel

Vertices List

Id-Map

Interface

Vd-Tree

NetWork

View Control

Shared Memory

Graphics Hardware

Triangles List

Client

Server Manager Server

Figure 4: View-dependent rendering over a client-server network.

scans the active-nodes list and tries to converge to the best visual appearance of the scene by increasing (merge operation) or decreasing (split operation) the resolution in various regions. After each update operation (split or merge) the interface packs the operation with the appropriate information and sends it to its associate client. Such approach leads to streaming the update operations to the client, which updates the graphics display on its convenient time (independent of the interface adapt loop).

4.2 Client Clients should know the connection information of servers from whom they are interested to seek service. Since each server application handles one dataset, a client can access a server by its dataset name(in our current implementation servers are identified by the name of the dataset they handle). Clients maintain a list of vertices and a list of triangles, which are sent to the graphics hardware at each frame. Practically, these lists represent the appropriate level of detail of the visualized dataset with respect to view parameters of the client. Nodes in the view-dependence trees are identified by their id-es, which are identical to their indices. However, the indices of nodes in the client’s address space differ from that in the server’s address space. Therefore, each client keeps a map to translate a given id to its appropriate index in the client’s address space. Clients also watch changes in the view-parameters and send the updated view-parameters to the server, which updates its active-nodes list appropriately. At each change of the view parameters on the client side, it sends these changes to its associate interface and updates the vertex and triangle lists according to the update operations it receives form its associate interface. In addition, it maintains immediate interaction with the user and sends the current level of detail to the graphics hardware.

4.3 Client-Server Communication In our current implementation we assume that the server and clients share a LAN network. Even though we believe that our system should work properly on a WAN network, we have not yet conducted any tests in this direction. The server manager

listens on a public channel, on a non-blocking mode waiting for requests from new clients. The public channel is a simplex channel (single direction) open for write-only by clients and read-only by the server. Through this channel, the server expects to receive only fixed-size packets which include the characteristic parameters of clients. The data channel is a private channel shared only by one client and its associate interface. Since, the data channel is a full-duplex channel (two simultaneous directions) the client and its associate interface send and receive data over this channel. The client sends the view-parameter changes and receives a stream of update operations and the interface receives the view-parameters changes and generates the stream of the update operations.

4.4 Communication Messages Since the server and any client run in two different machines, they relay messages to exchange information over the local network. They exchange various messages during the different phases of interaction. These messages appear in the connection diagram in Figure 5. Next we will briefly overview these messages.







Call-For-Connection message is sent by the client to the server through the public communication channel. This is a fixed-size message, which includes the client machine characteristics such as client-name, memory-size, average time to render 1K triangles, and minimum frame rates. ACK-Connection message is sent by the server to the client approving the connection. It includes the viewdependence tree parameters such as the number of root nodes, the number of triangles at the top level, and the number of leaves of the view-dependence tree. This message contains essential information for the client to initialize its internal lists and data-structures. Top-Level message is sent by an interface to its associate client to initialize the vertices and triangles lists. It includes the list of all the root nodes and the top-level triangles. Practically, this message includes the coarsest level of detail.

Time

Server Side

Connec

tion

Top-Level rs Changes

View-Paramete

Client Side

Call Aprove

Spilt/Merge Op

erations

rs Changes

View-Paramete Spilt/Merge Op

erations

ect

Disconn

Figure 5: Major Messages over One Connection Session.

 



checks whether the calling client satisfies the minimum requirement to visualize the server’s dataset. In case of a positive answer, the server approves the connection and creates an interface to handle the connection with the calling client. The interface then creates the data channel. From this point on the interface handles the entire interaction with the calling client. It is important to note that the interface has access permission to the shared memory where the view-dependence tree resides.

on

necti for Con

View-Parameters message is sent by a client to its associate interface to report changes in the view parameters such as camera position, view direction, and illumination. Spilt/Merge message is sent by an interface to its associate client for each split or merge operation the interface executes. This message includes a stream of operation that allows the client to update its vertex and triangle lists to match the active-nodes list of its associate interface. Disconnect message is sent by a client to indicate the end of a connection session. This message enables a clean release of the interface’s resources.

It is important to note that we rely on the data-network layer, thus we assume that the connection is sequential and reliable (packets arrive free of error and duplication and in the correct sequence). However, the system maintains a time-out on the data channel to detect critical simple errors. For example, if the client does not receive update operations when it sends changes in the view parameters to the server, it reports a time-out error.

Initializing: This phase starts when the server and a client are ready to exchange data (messages). The interface initializes its active nodes list using the root-nodes list of the view-dependence trees. Then it sends the coarsest level of detail to its associate client. On receiving the root nodes and triangles, the associate client initializes its vertex list and its triangle list. It also initializes a mapping from the node id-es and triangles id-es to the their appropriate indices in the client lists. Adapt Dialog: The client-server dialog enables the client to adapt to the best visual appearance of the scene with respect to its computation power, local memory, and rendering capabilities. The client sends its view parameters to the server’s interface, which updates its active-nodes list to adapt to better representation of the given dataset according to the received view parameters (taking into account the hardware limitation of the client). During the adaptation process the server’s interface sends to the client the added nodes and triangles, the removed nodes and triangles, and the changed triangles. These updates are sent to the client in a compact form of messages in order to reduce even more the load on the network. Disconnection phase: This phase is initiated by the client by sending a disconnect message. On receiving this message, the associate interface releases its allocated resources, sends an acknowledge message to its associate client, and ends the interface session. Only then the client application can exit. It is important to note that the client and server could enter the disconnection phase if the data channel times out.

6 5

Interaction Phases

The client uses the memory and computation power of the server to acquire the ability to visualize large datasets that exceeds its rendering capabilities. Since this process is done over a local network, it involves several different phases of interaction. Next we shall explain in detail these phases one by one. Server Setup: In this phase the server loads the viewdependence tree of a given dataset and opens a public communication channel at which it listens for users’ requests for connection. In our current implementation we assume that the given dataset has passed the preprocessing stage. Connection Setup: The setup phase initiated by a client. It sends its machine parameters such as memory size and rendering capability to the server through the public communication channel. On receiving this message the server

Sharable View-Dependence Tree

In order to adopt view-dependence trees to a shared multiusers environment we have made two major changes. First we separate the active-nodes list from the view-dependence tree and eliminate the active-triangles list. Second, we reduce the split/merge restriction imposed by the implicit dependencies by localizing the view-dependence tree. Recall that implicit dependencies [10] have been developed to prevent foldover at runtime by carefully assigning id-es to the nodes of the view-dependence tree. In addition, we have found that they (the implicit dependencies) enable the separation of the active-nodes from the view-dependence tree. This separation is a vital point in our system architecture, since it enables multiple interfaces to have different active-nodes list and share the same view-dependent tree. In addition, we have implemented implicit dependencies by keeping two integers for each active node. These two integers keep the maximum id of adjacent nodes and the minimum id of the adjacent parent. We updated these two id-es after each collapse and merge opera-

tion. At run time we need only to compare the id of the node with the two stored id-es. Implicit dependencies are used to avoid foldovers at runtime by preventing the collapse or merge of nodes before others. Hence, these dependencies often restrict the refinement of nodes, which might have otherwise refined to comply with the visual fidelity or error metric. Note that this phenomenon exists also in the explicit dependencies lists. One way to reduce such restrictions could be achieved by reducing the dependencies between the nodes of the tree, which could be done by localizing the view-dependence tree. By localizing the tree we refer to minimizing the distance between the nodes of the tree. To show how we localize a view-dependence tree let us first define the radius of a subtree as the maximum distance between the root of the subtree and any of its children. We are currently using the Euclidean distance metric to measure the distance between nodes. We have chosen to localize the view-dependence tree by minimizing the radius of each subtree. Since we construct the tree bottom-up, the algorithm starts by initializing each subtree radius to zero (each subtree has only one node). The effect of the collapse operation could be seen as a merge of two subtrees. Therefore, we collapse a node to the neighbor, which result in the minimum radius. It is important to note that our algorithm does not guarantee optimal radiuses for the final trees. In practice, it results in fairly acceptable small radiuses.

7

Implementation Details

We have developed our system using C++ over the Unix/Linux operating systems. It runs on various machines such as PC, SUN, and SGI. We have used the FLTK [25] library to design the graphics user interfaces. The communication channels are based on the Unix socket library. As we have mentioned, the view-dependence tree resides in the shared memory arena of the server. Each interface has read-only access to the shared memory to maintain its activenodes list. The active-nodes list keeps a record for each active node which include a pointer to the actual node of the viewdependence tree, a list of id-es of its current adjacent triangles, and two integers to maintain the implicit dependencies. Recall that on a view-dependence each triangle is stored only once, in the node which leads to its degeneration (actually, the node keeps the last non-degenerate form of the triangle). In contrast to previous implementations of view-dependence, we have found that we do not need to store the active-triangles list in the interface entity. They are implicit on the interface side but they have explicit representation on the client side. This approach reduces the memory required by the interfaces, which enables more clients to connect to the same server. View-dependent rendering algorithms usually store (in local or external memory) the multiresolution hierarchy on the rendering machine. Instead, our approach keeps only the selected level of detail as a list of vertices and a list of triangles in the rendering machine (the client machine). Such technique usually provides more memory space which enables the selection of larger (more detailed) level-of-detail representation for large datasets. In addition, the display process and the adaptation process run completely in parallel since they live in two different machines. This parallelization enables faster response to various user events. The client keeps a list of vertices and a list of triangles, which are sent to the graphics hardware at each frame. Instead of sending the whole vertex information with each triangle, we

have adopted the idea of vertex-array of OpenGL. In the vertexarray approach, we send a list of vertices then we send a set of triangles represented by three indices in the vertex list. But sending the whole list of vertices has often led to a lot of thrashing as a result of the limited buffers of the graphics hardware. Therefore, we have decided to subdivide the set of vertices and set of triangles into several sub-sets. Each sub-set contains a list of vertices and the associated triangles (shared vertices are duplicated). At rendering time we send these subsets one by one. For each subset we send first the list of vertices in a vertexarray form, then we transmit the set of associate triangles to the graphics hardware. This approach reduces the cache miss and hence the thrashing phenomenon. It is clear that the size of these lists depends on the graphics hardware memory size and the weights of each vertex and triangle. We have found that a size of 64 vertices for each subset leads to a good performance.

8

Results

We have implemented our architecture in C++ as two separate executables, server and client. Then we conducted several tests on various datasets using our unoptimized implementation and have received encouraging results. The results we are reporting next were conducted on various machines using the same local network. We have used the network of our department, which is a 10 Megabit (per second) local network.Therefore, we shall report the specific configuration we have used for each table of results. Since view-dependent rendering takes advantage of coherence between consecutive frames, it makes more sense to compare its performance over sequences of frames and not over one isolated frame. Therefore, all the results we are reporting in this paper were obtained using a sequence of frames. In table 1 we report the average of number of split/merge operations, data sent over the data channel, number of triangles at each frame, and the average time for a frame. These results were obtained using the configuration: the server runs on an SGI ORIGIN 200 and the client runs on an SGI O2 with 96 MB. As can be seen from Table 1 we have achieved acceptable frame rate even for large datasets. In the same time the average amount of data transmitted at each frame is quite low. We have also compared the performance of view-dependent rendering over a network (using our approach), local memory, and external memory [8]. The external memory algorithm relies on smart prefetching from disk, while the local memory algorithm counts on the operating system in managing the memory (by swapping pages). For each dataset we record a path which includes the camera parameters and illumination. Then, we compare the performance of the three algorithms over the same path for each dataset. Note that the camera parameters and illumination determine the selected level-of-detail (for the same simplification metric) and hence determine the set of rendered triangles (the quality of the resulting image). Therefore, to compare the performance of two view-dependent algorithms we use the same dataset and the same path, then compare the frame rates. One could also keep the frame rate constant and measure the quality of the resulting images. Since it is not easy to measure the quality of the images we chose to use the first approach. In table 2 we report some results by comparing the three algorithms. These results were achieved using the configuration: the server runs on an SGI ORIGIN 200 and the client runs on an SGI O2 with 80 MB. For the other two algorithms (external and local

Dataset Bunny DragonA BallJoint Buddha DragonB Terrain Steve David

Original Vertices Triangles 36 K 69 K 101 K 200 K 137 K 274 K 145 K 293 K 101 K 300 K 262 K 522 K 272 K 739 K 588 K 1,172 K

Triangles (K) 40 45 47 60 82 76 60 70

Average/frame Split/Merge (K) Memory(KB) 1.6 70 1.4 71 1.2 69 1.8 76 1.7 86 1.9 110 2.2 120 2.3 130

Time(ms ) 75 78 82 80 81 78 85 96

Table 1: Run time over a sequence of frames for various datasets. Dataset Bunny DragonA BallJoint Buddha DragonB Terrain Steve David

Original Vertices Triangles 36 K 69 K 101 K 200 K 137 K 274 K 145 K 293 K 101 K 300 K 262 K 522 K 272 K 739 K 588 K 1,172 K

Average Time(ms)/frame Local Extern Network 60 72 78 68 83 84 76 88 86 96 94 87 120 101 90 160 112 93 181 120 94 245 194 105

Table 2: Comparison of different view-dependent rendering algorithms.

memory) we have used the same SGI O2 with 80 MB (the client machine). We have found that for small models such as “Bunny” the local memory algorithm achieves the best frame rates and the network algorithm comes last. But, as the datasets grow larger, the network algorithm starts to catch up and achieves the best frame rates for large datasets. For small dataset the local memory algorithm runs locally and the external memory algorithm does not need to access the disk often but the network algorithm has to pay the network overhead. When the datasets grow larger the local-memory algorithm does a lot of swaps, the external memory takes advantage of smart prefetch, and the network algorithm needs only to maintain his display lists which are much smaller that the entire view dependence tree. The network algorithm has another advantage over the other two algorithms because the display and adapter processes run completely in parallel. Recall that the adaptation process, which selects the appropriate level of detail, runs on the server’s machine and only the display process, which sends the vertex and triangle lists to the graphics hardware, runs on the client’s machine. Figures 6, 7, and 8 show images generated by our system. The small window on the top-right corner of some images is the image seen by the user and the other window is the global view of the dataset. Figure 6 shows the full resolution of Dragon dataset (Figure 6(a)), and two different clients interacting with the same Dragon model concurrently (Figure 6(a) and Figure 6(b)). Note that the view-dependence tree of the Dragon model resides on a different machine (the server). The dynamic changes in the model resolution allow view-dependent rendering at interactive rate (about 10-14 frames/second). Figure 7 is the same as figure 6 for the Terrain dataset. Figure 8 shows the most possible detailed image of the Terrain dataset using view-dependent rendering over a network (Figure 8(a)) and external memory view-dependent (Figure 8(b)). We were able to achieve more detailed representation on the networkbased algorithm because the client has more memory available to represent one level of detail.

9

Conclusion and Future Work

We have presented a novel approach for view-dependent rendering of large datasets on an inexpensive workstation. Our idea is based on a client-server architecture over a local network. The view-dependence tree (a compact multiresolution hierarchy that supports view-dependent rendering) resides in a local server. A client (runs on an inexpensive machine) establishes a connection with a server and sends its view-parameters to the server which provides it (the client) with the appropriate level-of-detail representation of the scene with respect to the sent view parameters. We see the scope for future work in designing virtual environment application for hardware with limited memory size and rendering capabilities but still need to navigate through large datasets. Examples of these applications include (a) wireless head-mounted displays equipped with inexpensive computer and rely on a local server and (b) and large modeling firms in which several users with inexpensive machines interact with the large datasets. Current view-dependence tree does not support incremental changes. Therefore, the view-dependence tree is constructed, form scratch, after each change. The idea to perform changes in the tree locally could dramatically reduce the preprocessing time.

10

Acknowledgements

We would like to acknowledge the Weiler Family Fund which helped in purchasing some of the equipment used in this project. We also would like to thank Cyberware and the Stanford Computer Graphics Laboratory for providing datasets. Cyberware has provided the Steve, David, Knee, and BallJoint models. The Stanford Computer Graphics Laboratory has provided the Bunny, Dragon, and Buddha models. We are grateful to the reviewers for their insightful comments which led to several improvements in the presentation of this paper.

References [1] V. Anupam and C. Bajaj. Shastra: An architecture for development of collaborative applications. International Journal of Intelligent and Cooperative Information Systems, 3(2):155–172, 1994. [2] J. Baldeschwieler, R. Blumofe, and E. Brewer. Atlas: An infrastructure for global computing. In In Proceedings of the Seventh ACM SIGOPS European Workshop on System Support for Worldwide Applications, September 1996. [3] A. Baratloo, M. Karaul, Z. Kedem, and P. Wyckoff. Charlotte: metacomputing on the Web. In In In Proceedings of the 9th Conference on Parallel and Distributed Computing Systems, pages 2–12. International Society of Computers and Their Applications, 1996. [4] C. Blanchard, S. Burgess, Y. Harvill, J. Lanier, A. Lasko, M. Oberman, and M. Teitel. Reality built for two: a virtual reality tool. In Proceedings 1990 Symposium on Interactive Graphics, Snowbird Utah, pages 35–36, 1990. [5] B. Blau, C. Hughes, J. Moshell, and C. Lisle. Networked virtual environments. In ACM SIGGRAPH Special Issue on 1992 Symposium on Interactive 3D Graphics, pages 157–164. ACM Press, 1992. [6] W. Bricken and G. Coco. The veos project. tech-report FJ-15, University of Washington, Seattle 98195,WA, 1993. [7] C. Carlsson and O. Hagsand. Dive - a multi-user virtual reality system. In In Proceedings of the IEEE Virtual Reality Annual International Symposium, 1993. [8] J. El-Sana Y. Chiang. External memory view-dependent simplification. In Computer Graphics Forum, volume 19, page to appear. Eurographics Association and Blackwell Publishers Ltd 200, 2000. [9] J. El-Sana, E. Azanli, and A. Varshney. Skip strips: Maintaining triangle strips for view-dependent rendering. In IEEE Visualization ’99 Proceedings. ACM/SIGGRAPH Press, October 1999. [10] J. El-Sana and A. Varshney. Generalized view-dependent simplification. In Computer Graphics Forum, volume 18, pages C83–C94. Eurographics Association and Blackwell Publishers Ltd 1999, 1999. [11] J. Encarnacao, B. Tritsch, and C. Hornung. Dedicated learning on networked multimedia platforms. In In Visualization in Scientific Computing: Uses in University Education. IFIP WG3.2 Working Conference, volume A-48, pages 67–75, July 1993. [12] M. H. Gross, R. Gatti, and O. Staadt. Fast multiresolution surface meshing. In G. M. Nielson and D. Silver, editors, IEEE Visualization ’95 Proceedings, pages 135– 142, 1995. [13] A. Gu´eziec, F. Lazarus, G. Taubin, and W. Horn. Surface partitions for progressive transmission and display, and dynamic simplification of polygonal surfaces. In Proceedings VRML 98, Monterey, California, February 16– 19, pages 25–32, 1998.

[14] H. Hoppe. Progressive meshes. In Proceedings of SIGGRAPH ’96 (New Orleans, LA, August 4–9, 1996), pages 99 – 108. ACM SIGGRAPH, ACM Press, August 1996. [15] H. Hoppe. View-dependent refinement of progressive meshes. In Proceedings of SIGGRAPH ’97 (Los Angeles, CA), pages 189 – 197. ACM Press, August 1997. [16] R. Klein, A. Schilling, and W. Straßer. Illumination dependent refinement of multiresolution meshes. In Computer Graphics Intl, pages 680–687, June 1998. [17] M. Lewis and A. Grimshaw. The core legion object model. In In Proceedings of the Fifth IEEE International Symposium on High Performance Distributed Computing. IEEE Computer Society Press, August 1996. [18] P. Lindstrom, D. Koller, W. Ribarsky, L. Hughes, N. Faust, and G. Turner. Real-Time, continuous level of detail rendering of height fields. In Holly Rushmeier, editor, SIGGRAPH 96 Conference Proceedings, Annual Conference Series, pages 109–118. ACM SIGGRAPH, Addison Wesley, August 1996. [19] D. Luebke and C. Erikson. View-dependent simplification of arbitrary polygonal environments. In Proceedings of SIGGRAPH ’97 (Los Angeles, CA), pages 198 – 208. ACM SIGGRAPH, ACM Press, August 1997. [20] M. Macedonia, D. Brutzmann, M. Zyda, D. Pratt, P. Barham, J. Falby, and J. Locke. Npsnet: A multi-player 3d virtual environment over the internet. In ACM SIGGRAPH Special Issue on 1995 Symposium on Interactive 3D Graphics, pages 93–94. ACM Press, 1995. [21] A. Pang, C. Wittenbrink, and T. Goodman. Cspray: A collaborative scientific visualization application. In Proceedings Multimedia Computing and Networking, San Jose. California, February 1995. [22] M. Philippsen and M. Zenger. Javaparty: Transparent remote objects in java. Concurrency: Practice and Experience, 9(11):1225–1242, November 1997. [23] K. Rick. Making waves: On the design of architectures for low-end distributed virtual environments. In Proceedings of IEEE Virtual Reality Annual International Symposium, pages 443–449, September 1993. [24] A. Schilling and R. Klein. Graphics in/for digital libraries — rendering of multiresolution models with texture. Computers and Graphics, 22(6):667–679, 1998. [25] B. Spitzak. Fltk 1.0.6, 1999. http://www.fltk.org. [26] F. Thomas. Ring: A clientserver system for multi-user virtual environments. In ACM SIGGRAPH Special Issue on 1995 Symposium on Interactive 3D Graphics, pages 85–92. ACM Press, 1995. [27] J. Xia, J. El-Sana, and A. Varshney. Adaptive realtime level-of-detail-based rendering for polygonal models. IEEE Transactions on Visualization and Computer Graphics, pages 171 – 183, June 1997.