Parsec Networking Architecture
Together with Andreas Varga I am currently working on the design and implementation of the networking architecture of Parsec. This architecture subsumes a peer-to-peer protocol for game play on LANs (using IPX or UDP) and a client-server protocol for game play on TCP/IP networks, especially on the Internet. There are (currently not publicly accessible, but this will change in the future) dedicated game servers and a master server. Game servers register themselves at the master server from where they can easily be accessed by players via dynamically generated HTML pages. Players can connect to a nearby game server using Parsec (which in this context is the client) and play with each other regardless of where they are located geographically. The Documentation of the Parsec Networking Architecture is available online.

BspLib
BspLib is a C++ class library from which a BSP compiler for 3-D objects can be built very easily. It consists of a class hierarchy for handling three-dimensional objects, together with various processing functions, the most important of which is BSP compilation. An I/O class hierarchy is provided for importing and exporting 3-D data. Aside from proprietary formats, BspLib is capable of reading VRML V1.0 data files. The BspLib Documentation is available online.

ViewBSP
ViewBSP is a graphical front end to BspLib, combined with a simple object viewer. It runs on Windows 95/NT and uses OpenGL for rendering purposes. ViewBSP is able to read and write all formats supported by BspLib and display objects before and after BSP compilation. A simple tree view of the generated BSP tree is also available. You can view the ViewBSP Documentation online.

Blubb² Sound Card Project
This has been my biggest project combining both hardware and software (with emphasis on hardware). Together with Andreas Varga I developed an ISA soundcard capable of playing six independent music channels, firmware for the card, and some demo software. We started work in late 1992 and finished in mid-1994. Please have a look at the Blubb² Info Page I wrote for Andreas Varga's SID homepage.

Developing for Multiple High-Performance Graphics APIs Simultaneously: A Case Study
by Markus Hadwiger.
Done for the Central European Seminar on Computer Graphics (CESCG) '99 that took place from April 26 to April 27, 1999, in Budmerice, Slovakia.
 

Abstract:
In today’s world of interactive computer graphics applications the choice of graphics API is crucial, but still far from clear-cut. Especially when developing for consumer-level hardware the choice of API is very important, since it will have a tremendous impact on the potential market share, as well as performance and flexibility. Nevertheless, there is no single API that is definitely better in every respect than its competitors - particularly when developing for multiple platforms.
    The most important APIs, like OpenGL and Direct3D, support a multitude of graphics hardware via vendor-supplied graphics drivers. There are also proprietary APIs supporting only the hardware of a specific vendor. Although these are rapidly becoming more and more obscure, the Glide API by 3dfx Interactive is still ubiquitous in the area of entertainment software.
    This paper describes the process of simultaneously developing for multiple graphics APIs. We use Parsec, a three-dimensional space-combat computer game we are currently working on, as a case study. Parsec transparently supports OpenGL, Glide, and a proprietary software-renderer through an abstract interface layer encapsulating the underlying graphics API, without compromising performance.

The HTML version of this paper is available here.
The full text of this paper is available in PDF format.
There is also a GNU-ZIPPED POSTSCRIPT version of this paper available.
 
 

Abstract:
In the first part of my talk I am going to give an overview of the Parsec project, its history and goals, with a focus on its current state. I co-authored the first version of Parsec for the CG2&3 lab more than two years ago. Parsec is a 3-D space-fight game that is specifically targeted at network game play, that is, all opponent spacecraft are controlled by humans and there is no enemy AI. Aside from the basic concept, the Parsec of today has not much in common with this first version, though. There are native DOS, Win32 (NT/95), and MacOS (PowerMac) versions, and, although software-rendering is still supported, the current rendering subsystem of choice is the Voodoo Graphics by 3Dfx Interactive. There are currently five people working on Parsec in their free time and our next big goal is Internet game play.
   In the second part of my talk I am going to describe Parsec’s architecture. The structure of its code-base is highly modular, making porting easy. There are abstract subsystems for Audio, Input, Networking, System, Video, Drawing (2-D graphics), and Rendering (3-D graphics). These have to be implemented anew for each platform, but the bulk of the code need not be changed. If two different platforms support the same graphics API (say, Glide or OpenGL) Parsec may be ported to a new platform in under a thousand lines of code.
   At the end of my talk I will show a demo of Parsec running on a PC and a Voodoo Graphics card. This demo also contains music composed especially for this purpose.

I tried to capture the flow of the live demonstration in a series of snapshots.
Transparencies of the talk are available in PDF format.
 
 

Abstract:
One of the major goals in real-time computer graphics is to achieve high realism of rendered images without compromising rendering speed too much. Frame update rate requirements are especially demanding in the area of entertainment software. Player immersion is directly related to both the number of frames displayed per second and the visual quality of the images rendered in each frame. Traditionally, these two goals have largely excluded one another. In recent years, however, standard desktop hardware has become powerful enough to make real-time rendering of convincing virtual environments possible.
   This paper describes the rendering engine of Parsec, a three-dimensional computer game we are currently developing. In this, we are focusing on those parts of the rendering process that are not part of the standard transform-clip-draw pipeline for polygonal objects. We are rendering multiple layers to achieve different effects with techniques specifically suited to the nature of these effects. We use an image-based rendering approach to render an infinitely far-away background. Particle systems are employed to render effects that cannot easily be achieved with polygonal objects. Our software-renderer also harnesses multi-layer rendering to decouple specific rasterization tasks in order to gain significant speed-ups.

The HTML version of this paper contains additional screenshots.
The full text of this paper is available in PDF format.
There is also a GNU-ZIPPED POSTSCRIPT version of this paper available.
Transparencies of the talk are available in PDF format.
 
 

Abstract:
One of the most important problems in computer graphics is the classification of all objects in a scene as either being at least partially visible or totally invisible. The issue of rapidly identifying entirely invisible objects is of importance in any rendering system, but it is especially crucial when interactive frame update rates are desired.
   In an ideal rendering system it would be possible to exactly identify those objects that do not contribute to the generated image in any way at zero cost and, furthermore, to draw only the visible parts of those objects. Since we do not live in an ideal world, however, we try to make the process of determining all objects that are visible from an arbitrary dynamic viewpoint in a scene as efficient as possible. Thus, we want to cull all objects of a scene which are entirely occluded by other objects, or not even contained in the viewing frustum, in large chunks and with minimum cost per culling operation.
   This paper first gives an overview of several issues pertaining to virtually all visibility culling algorithms and then examines some of the most important work in detail. Additionally, we try to assess how some of these algorithms depend on the availability of a hardware z-buffer and how, if at all, they are practically applicable to software-only systems.

The full text of this paper is available in PDF format.
 
 

Abstract:
An implementation of a particle system as part of the rendering pipeline of a 3-D computer game is described. Due to the interactive nature of such a computer game one of the most important issues in this implementation is the real-time rendering capability of the created special effects. A short summary of the game’s rendering pipeline is given, restrictions on special effects without a particle system’s being integrated are described and used to show where tremendous improvements are possible with the deployment of a particle system. The fundamental changes of the original rendering pipeline necessary to accommodate the particle system are considered and looked at in detail. As an example of a special effect made possible by the introduction of a particle system the calculation and rendering of a lightning stroke is presented. Due to the nature of the application the emphasis is not on physically correct evaluation of a lightning beam but instead on visual appearance, i.e., the aim is not so much to make it look real, but to make it look like a typical special effect.

Have a look at some screenshots I showed during the talk.
The full text of this paper is available in PDF format.
Transparencies of the talk are available in PDF format.

If you want to get in touch with me, you can of course reach me via email: msh@cg.tuwien.ac.at