TigerHeart II: Objectives for the graphics engine

The 3D engine is the largest and most addressed extension of the first “TigerHeart” version. Because it is possible to use it not only for three-dimensional presentation but also for hardware-accelerated flat, 2D drawing the notation will be changed to the more indicative term ‘graphics engine’.
Following characteristics should be achieved:

  1. API base: It must be able to utilize Direct3D and OpenGL for hardware-accelerated display.
  2. Standardization: The objects should be accessible and modifiable independently from the graphics API, which is currently active. So a scene, which is created with DirectX, can be rendered with OpenGL and vice versa and tools and helper functions have to be created only once. Anyway the engine gains specialized interfaces, methods and attributes for particular API functionalities and performance issues.
  3. Object types: There are two major kinds of objects. Displayable ones (like graph nodes and polygon meshes) are unilaterally interdependent, transformable and have got the ability to be rendered and attributes like bounding volumes and a position vector. They use states (like shaders and textures), which are the second kind and on a par, for rendering. Besides octrees will help for culling and collision detection, fonts are being used by text objects to show letters, animations to transform nodes by presets, cameras for view manipulation and light sources for illumination.
  4. Multi-pass: Displayable objects should have the ability to be rendered multiple times using different sets of states. This is important for generating shadows, effects and complex lighting.
  5. Streaming: Rendering operations are stored into buffers, which can be sorted to reduce state changes and to meet other, hardware-dependent conditions for performance increases. These stream buffers can be processed in another thread than the generating one. That way the scenery is being modifiable for the next frame while the previous one is still being drawn.

XML for engineering

The Extensible Markup Language (XML) can be used to store any given data. I am using it to design functions, interfaces, classes and other types for the second TigerHeart engine.

Besides pure XML files, which store names, parameters, result types, derivations and so on, there are also a schema (XSD) and transformation files (XSLT).
The first one defines basic types and valid elements, attributes, groups and sequences for the XML files. So their syntax is checked for mistakes. Both kind of files are free from programming language specifications like class or virtual for C++.
For that XSLT is available to assemble files that are usable for coding. The greatest benefit of the whole system is the convertibility of the XML files into various languages and even multiple files of the same language (e.g. .h[pp] and .c[pp] for C). It is also possible to automatically generate bindings of functions and variables for scripting languages and to build a documentation in HTML or whatever you want. For TigerHeart II C++ headers, source code files and Lua bindings are formed. Maybe there will be a time when XSLTs for C# are added but they are not currently planned.

XML: schema XML: sample XML: transformation XML: result

After the transformations I can add content to the created source code. If I have to change a type name or a definition later, then I only need to do it once in an XML file and not at every appearance in the code.

TigerHeart II: Objectives for the core

The first important step in the planning phase of a new software project is to set the objectives. Here are the ones that should be achieved for the second version of the “TigerHeart” engine core:

  1. Classes and interfaces: C++ classes are accessed externally via interfaces similar to COM. Furthermore methods can be called and attributes can be retrieved and modified using special functions (e.g. for script utilization).
  2. Derivation: It is possible to use existing classes as base for new ones. But those extensions should be accessed by non-derived interfaces.
  3. Object and library management: TigerHeart manages object creation from classes, which are provided by static and dynamic libraries.
  4. Data access and storage: Files from directories and archives are loaded and saved using wrappers. Data can be stored into memory and files with a standard interface and compression.
  5. Meta data: Every class is able to retain user-defined attributes.
  6. Design: Construction of functions, classes and interfaces happens in XML files, which are transformed into various header, source code, script files and what ever is needed. These files will be enhanced by own code.
    Maybe the handling is simplified by an editor later.
  7. Threads: There is a native support for processing on multiple cores.
  8. x86 / x64: Code has to be compilable to 32 and 64 bit executables for Microsoft Windows XP and Vista. Compatibility with other platforms is optional.


After my first game “FutureTrade” had been published I started to learn 3D programming, which was a wise decision because I needed it for my first commercial graphics engine some month later. It was developed for “BomberFun” and also used for a winter sports game called “Winterspiele 2002” and its successor “WinterSports Extreme“. But in the development time I began to realize that the design was not very good. Even it was object-orientated it was made up of one giant class for the game and one giant derivation for the editor. The engine was fast but inflexible especially using shaders and it was no real fun to program with it.

Early in 2002 I started the planning of a new engine. It should be really object-orientated, perform more common tasks than only graphics and be nice to use. The design was adopted from “Microsoft DirectX” because I love how the objects live up to their names. I started the implementation after “BomberFun” was finished and a new project was started in late summer and named the project “TigerHeart” because it is a good name for an engine.
The base of the system is the main engine, which is responsible for object management like COM but platform-independent, loading extension libraries like a plug-in and data storage and access. Meanwhile some extensions have gathered but the first and most important is the 3D engine using “Direct3D“. Different from the previous one there are a lot of classes for the various functions and attributes: renderers (frames, bodies, meshes), states (textures, materials, shaders), animation data (animations, sets, blenders) and some more. They are used to build a hierarchy, which can be processed or rendered with one command.
Next I created an extension for scripting and one derivation for “Lua” support. It is completely independent from the 3D engine but can be combined with it smoothly because of the “TigerHeart” design. There is the possibility to add support for another language, which is applicable immediately without the need for a change of the target program. But up to now there was no demand for it.

TigerHeart sample TigerHeart sample TigerHeart sample

For our bowling, card and air hockey games I implemented a compilation of class, which were based on the “TigerHeart” engine. But they were not flexible enough and not clearly separated from the games themselves. So I started to implement a game engine base as an extension library for the main engine at the beginning of 2005. It handles initialization, standard scene management, script access, multi-threaded loading, some user interface functions, console support for development, input processing and sound output.
The first use was for “Uli Stein – Summer Games” and later for “Balko”. We also developed our broadcast applications for the “Four Hills Tournament” 2005/06 and “tvVAT3D” as an add-on for it.

TigerHeart sample

Every now and then there a some design issues and some missing features, for which time was lacking. But we still currently use the “TigerHeart” engine and extensions for the development of a casual game selection. Anyway the planning phase of the second version has just begun and I will use this weblog to keep you informed. Maybe that would help you to design an engine or maybe there are times when you are able to help me in difficult situations.

Back to television

In November 2005 we received an interesting request. A graphical artist, who once worked for Steffen Kleinke, was engaged at a company called “WIGE” in Munich. He phoned Steffen, because his employer was looking for team, which could realize a special real-time 3D live broadcasting project. “Media Seasons” was not the only studio in Germany with the ability to do it but we had luck. “WIGE INNOVATION” was the subsidiary company with the relating area of responsibility for such projects and fortunately situated in our city.

Get the Flash Player to see the wordTube Media Player.


The project definition was to build a tool, which can be used to view a soccer scene from television with 3D models from any perspective. The most important point was that one operator is able to adjust the camera placement, ten player poses and their texture setting from a frozen image in ten minutes. That tool was used in the live shows at the “2006 FIFA World Cup Germany™” by the German television broadcaster “ZDF” and the Austrian “ORF“. At that time “WIGE DATA” and “WIGE INNOVATION” were bought by “Swiss Timing“, which is part “The Swatch Group“, and renamed to “ST SPORTSERVICE” and “ST INNOVATION”. “ZDF” and “DSF” are still using our application called “tvVAT3D”.


ZDF Arena at Sony Center, Berlin tvVAT3D tvVAT3D

But before that happened we were asked at the beginning of December 2005 if we can develop a program that brings a virtual animated ski jumper into a real “ORF” studio for the “Four Hills Tournament“. The event was taking place between December, 28th and January, 6th in 2005/06. Although we had less than one month time, only a basic understanding for ski jumping and some new technologies like tracking of a real camera or outputting the graphics using the SDI ports of a “NVIDIA Quadro FX” card to integrate we accepted and mastered the challenge. We repeated the success one year later but used another software technology that time.