advertisement


Totality Engine - Part 2

An interesting article was added on Revolutionaries a couple of months ago, which brings to light some of the more technical details about the engine. Unfortunately, Revolutionaries closed a while back, but I thank the Revolutionaries team for writing such a comprehensive article, and letting me reproduce it here. However, I must point out that this was written in 2000, meaning that there is a possibility of errors in the article.

"Republic is thought to be using a form of rendering technology known as Image Based Rendering (IBR), which is also commonly known as Impostors.

IBR is all about caching complex geometry in textures so that instead of having 100,000 polygons to render every frame, you simply render a texture that these 100,000 polygons would make from the current view, and then use this to texture a considerably smaller number of polygons.

This results in a scene which would seem to have "rendered" 100,000 polygons in real time, when in fact the 100,000 polygons only needed to be rendered once, then saved as a texture, which is then reused until the geometry has changed so much that the image is now invalid.

The term "infinite polygon engine" is partially misleading. There will not be any other number of real polygons on-screen than with any other game. It may look better, due to the texture detail, but this is only a matter of perception.

However, this solution will only remain valid in the distance, where the polygons change very little in appearance as the camera moves. If this solution was used in the near camera area, it would look no better than many other games, where what "should" be polygonal detail is simply texture detail (e.g. the transparent chain-link fences seen in Quake style games, which when you get near to the fence it can be seen to be a simple texture applied to a single polygon rather than a polygonal wire).

Because of this, the near view will most likely be real time, although a degree of cached images will be used when possible for the smaller details. This might mean that the cherubs that can be seen in some of the screenshots will be texture detail until you get very close, then change into polygonal detail.

This solution gives very good-looking images, but limits some flexibility that a non-IBR engine might have. The geometry must be now be static, otherwise the whole texture would have to be re-rendered each time the geometry changed. This is not as much as a problem as it may seem, as real-time entities can be placed in the scene, for example cars and people, which are unaffected by these limitations.

One major problem is the storage of the cached images. This can be done in system memory (the "normal" RAM in your machine), or in the video ram (the RAM that comes in your video card). Ideally it should be stored in the video RAM, but this is generally only used when the texture will be needed to render the frame, so if it is off screen, it will be stored in system RAM. This might lead to a high minimum RAM requirement, as well as a large amount of texture thrashing between system RAM and video RAM, although this is one of the problems the AGP port on your motherboard was designed to solve.

The second problem of IBR is also related to the textures. Artifacts in the textures occur due to the fact that rendering a warped cached image is only an approximation to rendering the geometry again once the camera have moved. Another problem is that when using a texture that was rendered using different geometry, and the camera has moved, zooming in a bit, you don't want to have to re-render the texture again, so you reuse the image... only now each texel is a bit bigger, so the image looks blockier.

Although this shows some of the possible pitfalls of the engine, it is still head and shoulders above anything the other developers are using - and that includes Lionhead with Black and White which was a graphically superb game.

Next - the official line on the technology