Content on this page requires a newer version of Adobe Flash Player.

Get Adobe Flash player

Technical Concerns

At an elementary level, a religious ritual consists of (1) shared experience of a group of people, (2) coordination of actions, and (3) a sacred object (material or non-material) of worship (cite). In a virtual environment we can only design tangibles, i.e., objects that can modeled, pictured or programmed, like buildings, artifacts and avatars. Sacredness and shared experiences are intangibles that we cannot design but can only allow for.

As discussed before, a shared experience of Virtual Sirkap was of a paramount concern for us. This concern had technical implications on our choice of the medium of representation: It had to afford multi-user interactivity. We chose Torque: a 3D graphics engine developed by InstantAction for the creation and development of video games. Torque is an inexpensive engine that theoretically allows up to 64 users to simultaneously explore the virtual environment over a private network or the Internet. It also supports C++, one of the most popular programming languages available, opening up the engine for modifications according to the task at hand. Because Torque is relatively cheap, it enjoys a large developer base from which we can seek technical advice and buy content.

Torque has its disadvantages too. It has no internal tools for creating content. We had to buy modeling and scripting tools from InstantAction, and use sophisticated computer applications like Autodesk 3D Studio Max and Adobe Photoshop extensively. We were also responsible for the technical aspects of the optimization of the environment, which we will discuss in details later, and which had an impact on the design and experience of the environment. The apparent flexibility of Torque came at the price of a steep learning curve. In a virtual environment, users liberally explore the environment and interact with other users and NPCs. These interactions are channeled through an avatar: an anthropomorphic, usually gendered, 3D model that represents the user in the environment. Users observe the environment through a camera that is usually mounted either at the eye level of the userís avatar (first person view) or at a certain point behind the avatar (third person view). The environment, thus, appears to the user (or the camera) in a three-dimensional (3D) perspective view.

The primary role of the 3D graphics engine is to compute what the users see, through the camera, in real-time. When a user interacts with the environment, she expects immediate real-time feedback. Technically, the basic principle is that a central dedicated hardware/software computer system on which the environment is hosted (the server), sends data to the software running on the userís computer (the client). The client uses these data to construct a computer generated image, called frame. In order for the user to experience a smooth movement, the client needs to produce a large number of frames every second. A frame rate of 30 frames per second (fps) is conventionally accepted as the minimum.

Many factors are at stake to achieve a real-time user experience, including the design of the environment, the number of users, the network capacity, and the computation power of both clients and server. One strategy often employed by game developers is to represent an artifact by means of a simplified geometrical model. Designers, then, compensate for the loss of details by applying complex images as the modelís texture (texture map). Thus, all information pertaining to the artifactís details, surface texture, light and shadows, are ďbakedĒ into the image of the objectís material (Figure 1).

Figure 1: From left to right, a model of a pot without a texture map, with a standard texture map, and with baked texture map.

Another strategy for the optimization of the environment is the use of levels of detail (LoD). Most objects in the virtual environment have different alternative models with decreasing details and complexity. The richest model is computed when the object is closest to the camera while the poorest is computed when the object is furthest, significantly saving computation time (Figure 2).

Figure 2: Three levels of detail (LoD) used for a non-playing-character (NPC): A, B and C. Aí, Bí and Cí represent A, B and C respectively as they appear to the camera (the user) in the virtual environment. A is the richest in details while C is the poorest. The 3D graphics engine automatically replaces C with B and then with A as the NPC moves closer to the camera.

There are many other optimization strategies employed by game developers that we used in Virtual Sirkap and that we cannot explain in this paper due to space limitation. However, the purpose of exposing some of these strategies is to reflect on their impact on the representation of Sirkap in ways that we will discuss later in the paper.