TimeSplitters 4/Engine Requirements

* Note these changes were planned for the FRDEngine, the engine used in Haze and Battlefront III. In 2008, a new engine was made, for which we do not have documentation.

## Editor Requirements for TimeSplitters 4

Essential requirements that need to be in place and fully working/tested for the end of the year when production starts.

* **Creation of new levels/props/detailgeoms etc.** Artists need to be able to create a new asset of any type without having to get a designer to make it work in the game, e.g. from the editor, we should be able to create a background level, prop, etc. that can then be placed directly into the game.
* **Background Lighting.** The editor will be required to preview lighting in real time (or close to it). This will require manipulation of light objects, light colour, intensity (key frame animated later) and assigning type of light + other light parameters. In the editor, all lights will have separate shadow maps that only get combined prior to running the game. ‘Key lights’ will also have an assignable radius that specifies a bounding sphere volume. Only x number of spheres can intersect.
* **Assigning prop abilities.** Some of these will be TimeSplitters 4-specific and some will be for all games. The integration of Descript into the editor looks like it will be tedious and painful. Perhaps we can auto-generate a standard descript for a prop that explodes on health equal to zero. The important thing here is that at least there would be some visual feedback on how a prop will look when destroyed. Later, we could add more functionality to allow more specific behaviour.
* **Projective Decals.** To replace the current ‘layer’ decals (not layered shader!). Functionality should be shamelessly ripped off from UE3. Editor – projector that can be manipulated -quad height and width + cutoff distance + assign shader + realtime preview.
* **Shader Editor.** Something along the lines of the Quake III Arena Shader Editor, although obviously brought up to date to cover ‘next-gen’ shader tech. Any new shader types to be fully integrated into the editor as soon as they are created.
* **Layered Shader Tool.** Streamlining of existing functionality. Constructing the shader in editor should simplify this step considerably and prevent maintenance problems. Each layer mask should be able to be painted in realtime. Visual feedback about cost (depth) of layers on each poly will enable artists to be more efficient. This does not include UVing tools for now. The assumption is that this and the shader editor will be one and the same thing, utilizing the paint tool that the Battlefront team has created to make the layer blend masks.
* **Snapping tools.** To enable accurate placement of meshes in the editor – copy the snapping and pivot placement tools in Maya. This is very important to the way we are hoping to build levels in TimeSplitters. Individual meshes are built in Maya, but levels are constructed from connecting these meshes.
* **Performance Stats.** TimeSplitters 4 intends to run at 60 FPS. To do this, we will need to have this information available in the editor. Tri-count, batch count and texture usage and others to come, for each rendering types (props, background, detail geom, etc.). Other important visual aids will be portals, rooms drawn, bounding boxes of all visible props, detail geoms, etc.
* **Visibility.** Creating portals in the editor as well as imported from Maya. This will probably require the split poly tool to be integrated into the editor?
* **Ambient Occlusion**. *Yes please.*

Editor requirements that are important, but are not required before production:

* Creation of environment maps on a per-room basis (default capture point would be the geometric centre of the rooms bounding box).

## TimeSplitters 4 Lighting Technology

The proposed model for lighting will be different from those in Haze and Battlefront.

TimeSplitters 4 will be less concerned about radiosity and more concerned with dramatic moody shadowing (e.g. moonlight shadows). Levels will be largely indoor based. An important feature of the lighting model will be fast preview.

Direct lighting + Ambient Occlusion.

**Types of lights:**

* **Fill Lights** – Lights pre-computed, baked into lightmap, combined and encoded as SH. Pre-computed background shadows. Therefore, no shadows will be cast from props.

* **Shadow Lights** – Like fill lights, except they cast shadows from props. A shadow pass for all props flagged to project shadows.

* **Masked Light** (optimized version of Varying Lights) – These have a fixed position as well as fixed intensity and cast shadows. Each of these lights have a pre-computed shadow mask textures. As well as allowing shadows to be cast, surfaces can have per-pixel specular and reflections (bump mapping, parallax mapping…). Note that the diffuse component of the light is baked into the static light map. These can be LOD-ed very easily.

* **Varying Lights** – This time, the light is in a fixed position, but has varying intensity. This means that the diffuse component cannot be baked into the light map, thereby requiring a fully render pass for the diffuse component. Fixed cost and expensive. Examples of use will be flickering candles – specialized and infrequent. When off, they do not cost!

* **Flash Lights** – These lights have varying intensity and position, but do NOT shadow atall. Used for muzzle flashes, sparks, etc.

* **Fully Dynamic Lights** – The best and, of course, the most expensive! Requires a fully scenery pass. Used for lightning effects, etc. Hopefully, we can afford one of these.

* **Directional Lightmapping** (Half Life method) - This requires texture memory to store 3 lights per pixel on the texture. Potentially expensive texture memory-wise.

Double shadowing is only avoided by using fully dynamic lights. Therefore, double shadowing will happen – however, if the shadows are not too stark, we do not think it will look too bad. There are plenty of quick hacks that could be employed to minimize this. The varying / masked lights are an alternative method to the current Haze lights (in Haze, the specular contribution is approximated by a per-vertex weighted average of the fill lights – a big hack – fine for outdoor – these allow proper per-pixel specular calculations). It is unclear as to how expensive these lights will be, except they will be more expensive than the Haze system.

**Artist Tool Chain:**

Below outlines the main lighting requirements. It is quite possible that further methods might have to be used if we find that the quality and control is not sufficient.

MAYA

1. In Maya, the artist selects user-defined UV sets.

BACON

2. Offline bacon assigns UVs and merges with user-defined UV sets.

3. Bacon performs Ambient Occulsion pass. These will form the base texture for the final lightmaps.

GAME WORLD EDITOR

4. Any number of static lights are used to create directional lightmaps. These maps are re-computed every time the light is changed/moved. Therefore, we end up with a lightmap per light.

5. Masked/Varying/Dynamic Lights are edited and previewed as in game.

POST PROCESS BEFORE GAME

6. Combined lightmap is generated before going in-game.

## References

* editor\_requirements\_ts4.doc (16/05/2007)
* ts4\_technology.doc (17/05/2007)