Remote Rendering allows an application to run on a remote “server” machine and also do its 3D rendering on the remote machine, while displaying its user interface and 3D UserGuide_Images on a local machine. The power of Remote Rendering is that it allows users to view and interact with very large data sets from almost any client machine located almost anywhere.

Remote Rendering is a built-in feature of version 3.0 (and higher) of Open Inventor. Remote Rendering can be used with any standard VNC server and client, but has fairly high bandwidth requirements.

Remote Rendering allows a single graphics server to provide visualization for multiple client machines. Local client machines do not need any 3D graphics capability because rendering is handled completely on the remote machine. The local client machine only needs the ability to display UserGuide_Images. In some cases, multiple client machines can connect to the same remote session, enabling collaborative visualization without the need to share application data between the client machines.

Open Inventor remote rendering runs over standard high-speed networks. The client machine may be running an open source remote viewing tool like VNC ( www.realvnc.com), any X server (with or without 3D acceleration), or a commercial remote viewing tool like ThinAnywhere™. Remote rendering does not require any change to existing Open Inventor applications. It can be enabled simply by setting an environment variable.

Why Remote Rendering?

One reason is very large data sets. Rapid advances in both CPU speed and graphics performance have made desktop machines very effective for some 3D graphics applications. But for many data sets these machines still have limited capacity. Here are some of the issues:

• Graphics performanceLow cost systems may lack 3D acceleration, may not be able to handle very large numbers of triangles, or may have limited texture memory.
• System performanceLow cost systems typically cannot handle more than two processors and cannot achieve the high speed data transfer rates of servers.
• System capacityLower cost systems typically cannot provide multiple gigabytes of memory, terabytes of data storage, and so on. Graphics server machines are available with very powerful graphics, large texture memories, high speed buses, and even multiple graphics “pipes”. Server machines are available with large numbers of processors, very large memory, very large disk storage, and very fast transfer between these subsystems.

For various reasons it may not be possible to have either the data or the application physically located on the local client machine. The data might be too large to store on the local machine, or it would take too long to transfer the data over the network, or it is too difficult to synchronize a local copy of the data with a remote repository. In some cases security restrictions prohibit copying the data onto a local machine. It might be impossible or inconvenient to install and run a large application on the local machine.

Another reason is increased utilization of graphics server machines. These machines can be quite expensive, so most organizations can only afford to purchase and maintain a small number of them. Also, these machines and their associated storage are not easily moved and may have power or cooling requirements that are not easily met in remote locations. Allowing these machines to be used from remote locations greatly increases the return on investment (ROI) for the organization and may be the only way a remote user could gain access to the necessary computing/rendering power.

A final important reason for remote rendering is collaboration. Many problems are best addressed by a team, but often the team members are geographically dispersed and it would cost too much (in time and/or money) to bring them physically together. In some cases collaboration can be achieved by duplicating the data on each participant’s machine, but for very large data sets this is usually not practical. Remote rendering leverages the power of the remote server machine by rendering each image once and transmitting the image to multiple participants.

What About OpenGL Network Rendering?

Open Inventor uses the OpenGL™ API for rendering. On Unix/Linux machines, OpenGL has the ability to render across a network using the GLX protocol. This allows an Open Inventor program to run on a remote Unix machine and display on a local machine, provided the local machine has an X Window server that supports the GLX extension. In this configuration the application uses the CPU, memory, and hard drives on the remote machine, but all 3D rendering is done on the local machine. With a sufficiently powerful local machine, this can be an effective distribution of processing power. Good performance requires effective use of OpenGL display lists, but many Open Inventor applications have this characteristic because of Inventor’s automatic management of display lists.

Rendering using GLX protocol

overall system performance may limit application performance. Since the 3D rendering performance depends on the local hardware, it may not be effective for applications (or data sets) that need to render a very large number of triangles or use very large textures (for example, volume rendering). More powerful 3D graphics hardware increases the cost of the local machine. Network bandwidth may limit performance. Since all the textures and geometry must be sent across the network, it is usually not effective for applications that need “immediate mode” rendering or frequently replace display lists or texture objects. Finally, the local machine must be running an X Window server that supports the GLX extension and can take advantage of a 3D graphics board.