GitHub Page About


A blog on various development topics

Rainbow Six Revival Project

Rainbow Six and it’s sequel Rogue Spear are early defining games in the tactical shooter genre and the legacy remains today in Rainbow Six: Siege.

I’ve been working on extracting data out of Rainbow Six with the goal of bringing it into a new engine and recreating the game.

Preview of the first mission in Unreal Engine 4 First attempt in Unreal


Early last year I wanted to play these games, unfortunately it turns out it’s quite hard to play these games on modern systems. Rainbow Six is available from GOG although it has some rendering issues and I was unable to get the mission pack Eagle Watch working. I also had no luck getting Rogue Spear to work from my CDs.

It’s a shame these 2 games are so inaccessible these days, and I wondered how hard it would be to extract the data and put them into a modern engine. So one of the projects I’ve been working on in my freetime is exactly that. Over time I’ll write about a few of the interesting challenges faced throughout the project such as:

The ultimate goal is to rebuild the game code from scratch, but the first step is extract all the assets out of the files.

Extracting the data

Regardless of if or how the project will end up being released, the content is still copyrighted so the goal is to have a fully automatic process that will convert the assets to open or standard formats which can then be loaded by the new engine on an end users computer without any technical input needed.

I’m using blender for a lot of the 3D and export operations since it’s open source, already has support for a lot of formats, and can run in batch/headless mode.

After some research I stumbled upon a github repo by Alex Kimov, which already had a great deal of formats partially documented. The layout of most file formats is mostly documented, with the actual contents of the data structures still being incomplete. This has been a great starting point. Once I began writing python scripts to parse the files I was able to start discovering what many of the undocumented parts meant. Alex and I have been collaborating a lot, sharing a lot of knowledge back and forth which has been really helpful.

This has been an interesting problem, I’ve never really had to work backwards in this way on a file or system. It’s an interesting perspective. Remembering how the fixed function rendering pipeline works has been a walk down memory lane, since that’s what I first learned with OpenGL, but I haven’t used it in a long time. It’s so easy just to think in terms of shaders these days you forget how much could be done in the fixed function pipeline. This whole process has been as much about research as it has been about analysing files. Looking up old modding SDKs for the games, the DirectX 8 SDK and tutorials for hints about data structures and rendering functionality. These resources are much harder to find these days because either the sites are gone, or they’ve been de-ranked by search engines due to age and popularity.

Rebuilding the game

This stage hasn’t started yet. I’d like to remake both single player and multiplayer. To ease the amount of work required for that I’ll probably elect for a more complete engine like Unity or Unreal, rather than go down a similar path to OpenSAGE which is trying to redevelop the engine and open the original binary files at runtime. The idea of a WebGL implementation does have some appeal though, since it’s quite an old game which won’t require much processing power.

There are a few factors that I still need to weigh up which will help decide on a final engine:


The goal is to make a completely automated process which can read the original assets and output the data to open or standard formats. I’m using a variety of software to do this. Here are some of the key interesting ones.

Python 3.7

All scripts are currently being written in python 3.7 since it’s really quick to iterate with and there is a lot of software that is already easy to interact with. This means with minimal or no changes the same scripts can be used in Blender, and potentially the final engine.

Blender 2.8

I’ve chosen to rely heavily on Blender for this project since it has well tested 3D operations that I won’t need to rewrite, as well as excellent format support for converting to other engines. Since starting the project I have upgraded the scripts to the new beta Blender 2.8 since this isn’t a production project and the goal is future proofing.

010 Editor

010 Editor is a hex editor on steroids. This is a piece of software I only became familiar with based off Alex’s work. It is incredibly useful for exploring data formats. If you ever have a need to extract data from an unknown format, or recover a corrupted file, or a hex editor in general, definitely look into this software. It’s amazing.

Current Progress

So far I’m able to completely read all textures, static meshes and have mostly decoded/imported map files. This is the project repository and I’m tracking the progress of file formats here. I believe the majority of the work was in the level format which is mostly decoded now, but there is still a lot to go with some remaining challenges.


Materials are almost completely understood however texture sampling methods, translucency and alpha masking are not yet configured in the Blender materials. Materials don’t tend to move between software packages especially well. I’m better off redoing the materials in a more complete way in the final engine, so this is really low priority for now.


Lighting is still being worked on. Ambient lighting isn’t currently configured. Fine tuning the lights themselves will be quite time consuming since modern rendering is actually quite different from the technology that was used back in the late 1990s.

The original games use Vertex Lighting while modern rendering is based on Per-Pixel Lighting. Vertex lighting can still be setup, though I’d prefer to move towards per pixel lighting since it will simplify material setup and allow easier progress towards a HD pack. The main visible issue is currently it’s obvious that lights are placed away from what a player expects would be a light source like a lamp or street light. This was done to drive the vertex lighting in a very controlled way, however it becomes quite apparent with per pixel lighting.

Below are some examples of the strange placement of lights Example of lights clearly setup for Vertex Lighting Example of lights clearly setup for Vertex Lighting

Here is a let’s play by sigonsteele that shows how it looks in the original game. Skip to 9:05.

Many modern renderers are moving towards a model known as Physically Based Rendering. This describes how lights behave and interact with the surfaces and materials in the scene. Rendering previously has relied on a much simpler model. The old model only defined an ambient, diffuse and specular property as described here. The lights also shared these properties so lights could give a different specular highlight to the diffuse color the light was producing.

Lights also had 3 attenuation properties constant, linear and quadratic. These could all be changed to achieve different effects, however they have mostly been replaced with newer attenuation methods. There will need to be some fine tuning to map the old values to newer lighting models.

Finally, some screenshots of the progress

Rainbow Six Mission 01

Office in Embassy M01

Rainbow Six Mission 02 and it’s re-release in Rogue Spear Urban Operations

For reference, here is a let’s play by sigonsteele of the mission in the original game.


Rainbow Six M02 Rogue Spear M02


Rainbow Six M02 Rogue Spear M02

Sitting Room

Rainbow Six M02 Rogue Spear M02

Rogue Spear Mission 5 - Example of impossible geometry

From outside the aircraft you can see the Business Class cabin, and others RM05 From Inside the Business class cabin you can see it’s quite large and furnished RM05

Stay tuned for more progress updates soon!