Terrain manager uses a continuos LOD triangulation scheme, similar to a lot of systems that have appeared recently. Together with the use of caching and frame coherence, it is possible to achieve 1000:1 reduction of triangles in less than 1ms on a P II 333 MHz. This together with tiles that split allows us to draw 300km worth of 3d terrain for a flight simulator with a 64-meter grid on the highest level, or 2km worth of terrain to walk on with a 25-cm grid close by. This can be achieved with 3000 - 5000 triangles for a 2-pixel screen space error, and as little as 800 - 1200 triangle for 5 pixel screen space error. (These values are approximate and depends on the terrain in question)

Terrain manager also caches a unique texture for every section of the landscape. Yes that is correct, no repeating textures. You can have a unique texel on every section of the landscape. Using the default database, this takes up about 5 ms every frame.

Completely independent of operating system, or 3d library. The libraries are completely independent of both operating system, and 3d libraries. It will compile and run under windows, linux, or any of the consoles. This comes at a small price at integration time. All the 3d api specific implementations have to be done in the user's code. However, we have full onsite integration support after a sale, helping you to do the integration process as painlessly as possible.

Terrain Manager links into a database at runtime. The default database manager, as well as its specifications and source code will be available soon. This means that you will be able to alter the workings of the database to suit your needs, as long as all the runtime function calls are correctly implemented.

As an example, 3d objects like trees are currently stored individually with a position, rotation and scale. This works well for buildings etc, but it is possible to develop mathematical functions capable of placing these trees in a reliable way. The database can be change to encapsulate these functions, and solve the positions mathematically at runtime whenever a tile has to be cached.

Changes like these will also continually be incorporated into the default database.

Dynamic Eye Adaptation modeling is a system that models the light/dark adaptation of the human eye, or any other adaptive sensor like CCD cameras. In real-time, it measures the light that falls on the surface, and updates the render parameters to reflect this situation.

It can be used to accurately model the processes of the human eye (e.g. walking into a dark room, unable to see anything, and slowly over time starting to see more and more detail). Or it can be used to model the light meter of a video camera, adapting to the scene for best brightness and contrast.

In addition, because it samples the back buffer "accidental" light flares will also show up. In current systems, only defined lights can generate light flares, since the position, and visibility of the light has to be known. However, by sampling the back buffer, lights that reflect of curved surfaces, using environment maps will also be seen to generate flares.

Motion blur is one of the least looked at aspects in real-time rendering. It makes no sense rendering multiple frames to generate a motion blur, since you could just use the higher frame rate.

Real-time motion blur is achieved through a matrix scaling effect, and delivers effective motion blur with almost no overhead.