RayTracing Distributed System Humberto Martínez Barberá Secc. Redes y Comunicaciones, Universidad de Murcia
[email protected]
Antonio Gómez Skarmeta Dpto. Informática y Sistemas, Universidad de Murcia
[email protected] Abstract In this work we present the analysis and decissions taken to develop a distributed raytracing system. We will detail the options analyzed, as well as the solutions adopted to get a multiplatform and flexible system under the client-server paradigm. In this way, the system will improve the performance of computer based animation workers that make use of raytracing techniques. Moreover, due to modular architecture, the system could be utilized in many other types of calculations. Keywords: Distributed Systems, Computer Animation, Raytracing.
1
Client-Server
Model,
Introduction
Computer graphics (and especifically rendering techniques) are utilized in different areas like: Engineering, Architecture, Art, Education, and so on. The basic concept is to get a virtual image from a mathematic model. This type of production requires too many resources and equipments, and moreover, animations require a great deal of time to be generated (a very high waste of CPU time). At present, with the software available running in low end hardware, it is not posible to design an animation at the same time it is being generated in the same machine. Modus operandi in a traditional system would be like: designer plans the animation and makes related tasks (3D modelling, textures, etc) in his computer. When this has finished, the scene generation starts. This will take a while. At this point designer has two choices: to wait until the process finishes, or to continue his work in another computer. An inmediate solution is to duplicate machines. Resources are always limited, so this solution can be taken merely only as puntual solution but not as a definitively one. Taking into account that LANs allow resources be shared (particularly the CPU), the inmediate idea is to make use of LANs. In this way, the Distributed RayTracing System project (DRS) is born [2]. Conceptually, the idea is simple. The system is made of three kind of processing elements (Figure 1), interacting between them using the client/server paradigm:
- client machines are general purpose computers where users work. They are the entry points of the system with the human-machine interfaces. - processor machines are specific purpose computers where works are calculated. These computers could be rack-mounted motherboards, without disks. - server machine is the computer who accepts tasks and dispatchs them to the processors.
CLIENT 1
CLIENT 2
SERVER
PROCESSOR 1
PROCESSOR 2 PROCESSOR 3 PROCESSOR 4
PROCESSOR 5
Figure 1: General view of DRS elements links. In the next section we will detail a global view of the problem to solve, as well as the resolution mechanism. Next we will show the architecture that has been chosen for the system, and a briefly description of the elements. Finally we will point some possible improvements to the prototype that has been developed.
2
Design and implementation
Once we defined the elements that compound the DRS, from the implementation point of view we were interested that our DRS system could be characterized with the following properties: - must be necessarily multi-platform, - development tools must be standard, - must be independent of the raytracing kernel, - must be easily modified to perform any kind of calculations (i.e. not limited to raytracing), - both graphic libraries and communication protocols must be easily reusables. In the development of the DRS are involved some disciplines. In order to develop a system with the characteristics we have specified above, we need to adopt solutions that mainly fall into three categories: - communications: those tasks relatives to the information transmission, as well as system state changes. They will be based upon client-server paradigm, and will run over TCP/IP protocols stack. [1] & [3]. - interfaces: modular GUIs to make tools to help animation designer. Here will be used Open Interface graphic libraries [5].
- rendering: methods to create fotorealistic images. As it has been saying, we will use raytracing, as a rendering technique, with the RayShade kernel [6]. At present, there are some comercial packages that make use of LANs resources to make rendering (like PiXaR's Net-RenderMan and Autodesk's 3D Studio/Net), although in a limited way because they do not fit in the properties we have indicated as desirable. One example more elaborated is the NRT (Networked Ray-Tracing [4]), with a client-server architecture. Such system has a client module, where works are generated, and some processor modules, where images are calculated. In this package, communications rely over TCP/IP with RPC [4] & [3], which is inflexible as NRT is a very simple example, which does not have a communication protocol useful for a real use. Among others, the more important limitations of NRT are: - does not permit multiple clients, - the number of processors is software coded. In case more power is needed, the software must be recompiled, - very dependent of the raytracing kernel, - single image oriented.
3
System architecture and communication protocols
The general structure is based upon the client-server paradigm. In a tipical execution environment, we will have one or more clients, one server and one or more processors. Due to its architecture, we can make users benefit from the easily scalable system properties fitting their processing requirements simply by adding CPUs with processor software. In order to interconect the different elements, we have defined the following protocols (Figure 2):
XDCSP
CLIENT
SERVER
- XDCSP (XDray Client-Server Protocol): protocol for sending scenes from client to server, with some control information (username, work identification, etc). It will poll server to receive calculated data. - XDSPP (XDray Server-Processor Protocol): protocol for sending one scene from server to processor. - XDPSP (XDray Processor-Server Protocol): protocol for server be notified the processor availability /unavailability status, for sending statistics and for sending calculated data.
XDPSP
PROCESSOR XDSPP
Figure 2: SDR elements interconnection protocols.
Last two protocols are closely related, and are complementary. All protocols, that lie between OSI levels 5 to 7, have common important characteristics. They offer reliable conectionless-oriented services, over reliable conection-oriented level 4 services. All communications, based in a message-passing scheme, follow a two phases protocol: clientside starts connection sending request to server-side, who answers sending results or confirmation. Level 4 link starts when a message is generated and it is held up until the two phases protocol is finished. By this way of communication, we get both simpleness and flexibility, and whatever the reason we have to send a request, the fashion is always the same. For a complete description of the protocols see [2].
4
DRS elements
In this section we will briefly describe the DRS elements implementation. The programs that support each implementation of the elements are: - xdrayproc acts as the server-side module for the XDSPP protocol and as the XDPSP client-side module. The raytracing kernel receives data in XDLDE format (scene description language [6]). This program is very modular, so it is very easy to change the kernel to perform other types of calculations. - xdrayserv acts as both the XDCSP and the XDPSP server-side modules and the XDSPP client-side module. It has to manage element queues: users, batches and processors. Moreover, it has to translate client data format (XDLDA) to processor data format (XDLDE). In order to do so, we have implemented a traslator written with the compiler generators tools lex and yacc. - xdray acts as the XDCSP client-side module. Basically, it is a three dimensional graphic interface so users can perform all animation related tasks. Below, two snapshots of the program xdray are included (Figures 3 and 4).
5
Conclusions and future trents
Once we have finished the design and development phases, we have obtained a prototype to whom correspond the snapshots shown (Figures 3 and 4). A series of improvements, that are left pending, fall into three categories:
Figure 3: xdray window showing some elements and their paths.
Figure 4: xdray window to control client to server comunications. - client improvements: xdray incorporates a set of basic functions, but there is no option for 3D modelling. This could be the major improvement to this module. Another one could be algebraic path definition besides the implemented graphic path definition. - raytracing: traslation between xdray objects (Bèziér patches, textures, colours, etc) to xdrayserv objects is not very accurate, but this is not complex due to its modularity and the use of lex and yacc tools. It would be interesting to analize different raytracing granularities, to manage processors load [4]. - protocols and communications: this is the more accurate part of the implementation, from a functional point of view. It incorporates the minimum set of functions to permit DRS work at full profit in a real work environment. However, it would be interesting to implement automatic polling to detect the presence/absence of processors, and enable XDMSP (XDray Manager-Server Protocol), as shown in Figure 5. Although both protocol and code have been developed, at present we have not implemented a supervisor program. What it is important, is that we have developed a modular and distributed solution to a complex problem like this one of the animators designers, that involved not only
XDCSP
XDPSP
PROCESSOR XDSPP
XDMSP
CLIENT
SERVER
communications aspects but also man-machine interaction through a graphical interface in a client-server architecture. By this way, we have designed a general aproach to a series of similar problems which only differs in the type of calculations, developing a complete set of libraries for distributed computing.
SUPERVISOR Figure 5: DRS elements interconnection with XDMSP protocol.
6
References
[1] Martínez, H., "Internetworking and Communications", Instituto Murciano de Tecnología, Murcia, 1994 (in spanish) [2] Martínez, H., Skarmeta, A. G., "Client-Server system for network calculations: RayTracing Distributed System", Technical Report, Universidad de Murcia, Murcia, 1994 (in spanish) [3] Comer, D.; y Stevens, D. ,"Internetworking with TCP/IP", Prentice Hall, New Jersey, 1993 [4] Bloomer, J., "Power Programming with RPC", O'Reilly & Associates, Sebastopol, 1992 [5] Data, Neuron, "Open Interface Elements: API Reference", Neuron Data Inc., Palo Alto, 1993 [6] Kolb, C., "RayShade User's Guide and Reference Manual", ftp://ftp.um.es/pub/unix/graphics, 1992
