Tomb Raider Forums  

Go Back   Tomb Raider Forums > Tomb Raider Level Editor and Modding > Tomb Raider Level Editor > Software Development

Thread Tools
Old 23-02-13, 21:21   #1
Lwmte's Avatar
Joined: Aug 2010
Posts: 1,827
Wink OpenTomb project

OpenTomb (formerly TRE) is an engine replacement project intended to play levels from all classic TR games (TR 1-5) and custom levels.

For latest updates, downloads and source code, refer to OpenTomb official page. Latest news on project are currently available through ModDB entry. Also, check out our official YouTube channel!

Last edited by Lwmte; 28-07-15 at 13:22.
Lwmte is offline   Reply With Quote
Old 23-02-13, 21:22   #2
Lwmte's Avatar
Joined: Aug 2010
Posts: 1,827

OpenTomb Features:
  • Integrated LUA scripting: lately LUA became de-facto standard for game scripting because of its easiness and features. It is used by OpenTomb for flexible item, trigger and general gameplay programming on a per-level basis. Meaning, you can easily re-program ANY item or trigger for any level. Say goodbye to hardcoded item and trigger functions!
  • Shader-based rendering: OpenTomb does not use fixed-function pipeline for rendering, instead opting for shader-based pipeline. It means that engine takes full advantage of modern video chipset features - currently, it allows shader-based skinning, underwater effects and pixel lighting!
  • Completely different collision approach: engine uses special terrain generator to make every room's optimized collisional mesh from floordata. As for static mesh and movable collision - it is calculated on the fly and is not taken from pre-defined bounding boxes. Simply said, OpenTomb sees no difference between room, static mesh and object collision, and allows standing / climbing / etc. on any surface, including static meshes and movables (even enemies!).
  • BULLET physics engine is another groundbreaking feature, which offers industry standard quality object interactions in real-time. In OpenTomb, it is used for Lara's ponytail, boulders and other traps, as well as ragdoll death animations. In the future, Bullet will be used for ropes, particles, weather effects, and maybe something more.
  • Advanced audio engine: PC versions of Tomb Raider had no environmental audio effects, like echo, reverb or occlusions. OpenTomb successfully reimplements all these, plus air absorption effect and underwater low-pass filter! Soundtrack player uses three-channel automatic handling, which allows to play background ambience, action music and speech all at the same time without interruptions!
  • Cross-platform compatibility: OpenTomb is being written in C++ using unified interfaces like SDL 2.0, OpenGL and OpenAL, so it can be made compatible with any common platform, like Linux or Mac. Currently, Cochrane already made Mac port of OpenTomb, and vobject has made code compatible with Linux.

  • Q: What is OpenTomb?
    A: OpenTomb (previously known as TRE, tr1_engine or TeslaRus engine) is a reimplementation of classic Tomb Raider engines with support of all TR1-5 levels (excluding encrypted TRNG and TREP custom levels). It is being written from scratch, i. e. it's not a mod, patcher or dll extension of existing engine(s). OpenTomb uses some parts of previously abandoned TR engine clones - particularly OpenRaider and VT project, plus it incorporates some code from Quake Tenebrae project.
  • Q: Why develop another TR engine from scratch, if we already have TRNG, TREP, etc.?
    A: Despite the fact that patchers offer lots of customizations, they still operate within almost 15-year old binary with outdated graphics and sound, lack of modern hardware features support, no optimizarions, no proper physics model, and many more. Also, it is much more difficult to insert new features into pre-compiled binary than write it in high-level programming language. Plus, open-source model of OpenTomb allows anyone to contribute to code, with any degree of involvement.
  • Q: Why it's called OpenTomb, and why it was renamed from TRE?
    A: First of all, there are too many software projects with TRE in their names: TREP, DxTRE3d, TREE4. Second reason is Core themselves always used Tomb word as internal engine names: Tomb2, Tomb3, etc., so OpenTomb name (unlike, for example, OpenRaider) clearly marks itself as the next step in Tomb family. And the third reason is that it's simply a funny play of words: open tomb means to uncover something that was buried or forgotten - an old engine with numerous unsuccessful open-sourcing attempts, which finally gets uncovered!
  • Q: Where to download latest version of OpenTomb?
    A: Currently, we use Github for source code and SourceForge for nightly binary releases for Windows. So if you simply want to download and play the game, just follow this link. And if you want to contribute or simply research the source, follow this link.
  • Q: What do I need to run OpenTomb?
    A: It's all simple - you need all classic TR game resources. Problem is, these resources (except level files themselves) are tend to be in some cryptic formats or incompatible across game versions. Because of this, you need to convert some game resources by yourself or get them from somewhere on the Net. Anyway, here is the list of all needed assets and where to get them:
    1. Data folders from each game. Get them from your retail game CDs or Steam/GOG bundles. Just take data folder from each game's folder, and put it into corresponding /data/tr*/ folder.
    2. Audio folders from TR3-TR5. As with data folders, take audio folder from each of those game's folder, and put it into corresponding /data/tr*/ folder.
    3. CD audio tracks from TR1-2. To enable music for TR1 and TR2, you need their CD soundtracks in OGG format. You can download individual TR1 and TR2 soundtrack packages for TR1 and TR2 right here, or whole TR1-TR2 package right here.
    4. Loading screens for TR1-3 and TR5. For TR3, get them from pix directory of your installed official game. Just put this pix directory into /data/tr3/ folder. As for other games, it's a bit tricky to get loading screens, as there were no loading screens for PC versions TR1-2, TR4 used level screenshots as loading screens, and TR5 used encrypted format to store all loading graphics. So, to ease your life, you can simply download loading screen package here. Just put it right into OpenTomb directory, and that should do the trick.
  • Q: Is OpenTomb compatible with TRLE levels?
    A: Yes, latest revisions successfully loads TRLE custom levels - both classic and NGLE ones, except encrypted NGLE levels.
  • Q: Which features are currently available and which are not?
    A: Basic physics interaction – you can walk, run, jump, climb, swim, grab and shimmy ledges, slide on slopes and stumble into walls. In TR2+, you can climb walls. In TR3+ levels, you can also monkeyswing, crouch, crawl and sprint. Lately, triggers and switch/keyhole interaction has been also implemented. Also, you can pick up items, use them on keyholes/puzzleholes, as well as combine item pieces in TR4/5. However, there's still no proper menu. Also, no AI or NPC has been implemented yet.
  • Q: Why there are so many bugs in Lara's movements – landing and jumping animations are not assigned properly, some of intermediate animations are missing, etc.?
    A: Just because all code for Lara's states and state changes is being written completely from scratch. It's hard to precisely replicate original TR Lara behaviour, if you don't have original source code. Imagine that you learn Lara to walk and jump, like she's a little child. So it will take some time to polish gameplay and make Lara behave like she usually does in original games.
  • Q: What about Tomb Raider Xtra compatibility? And will it handle external textures for other game versions?
    A: There are plans to support replacement textures, including Tomb Raider Xtra. This should be relatively easy task, since the code is fully open (unlike old tomb* binaries, which require cryptic setups and filehacks to replace something in them).
  • Q: What about meta2tr'ed levels?
    A: Latest revisions of OpenTomb successfully loads and renders levels modded with meta2tr.
  • Q: Will it be compatible with TRNG/NGLE?
    A: Since TRNG is a patcher for Tomb4 engine, and OpenTomb is not a Tomb4 engine, it won't be compatible with it out of the box. However, most routines and special effects used in TRNG could be easily replicated with Lua scripts, and TRNG extended script could be translated to OpenTomb. So, in the end, it could be made compatible some day.
  • Q: Will it be compatible with TREP/FLEP?
    A: TREP and FLEP operates directly with engine binary, so it won't be possible to translate special TREP and FLEP routines to OpenTomb. Hence, no compatibility with TREP/FLEP is possible. However, eventually authors of TREPped and FLEPped levels could translate it via Lua scripting. Just make sure you have your TREP and FLEP presets stored at the safe place to revive them when OpenTomb will be ready for it.
  • Q: What about pixel shaders, SSAO, real-time shadows, environment mapping and all other fancy graphical features?
    A: Answer by Cochrane: all those requests are fairly simple, and TeslaRus's work is an excellent foundation to add these things. So yes, these will be implemented eventually. They're just not particularly high priority right now.


OpenTomb supports mouse, keyboard and joystick (force feedback support included for XInput controllers). Mouse is used for positioning camera, analog joystick/gamepad sticks also may serve the same purpose. As for button actions, all of them may be remapped via configuration file with "bind" command. Button keycodes are placed into "scripts/control_constants.lua" file (you can open it with any text editor).

If you're using joystick, note that joystick buttons are coded as JOY_ + button number, e.g. joystick button 1 should be coded as JOY_1 config file, joystick button 4 will be JOY_4, and so on. As for POV switch, directions are coded JOY_POVUP (up), JOY_POVDOWN (down), JOY_POVLEFT (left) and JOY_POVRIGHT (right).

Also, note about XInput controllers (XBOX360 controller and equivalents): its triggers have their own button names - JOY_TRIGGERLEFT and JOY_TRIGGERRIGHT. If you have gamepad which can switch between DirectInput and XInput modes, each mode will use its own mapping, but I recommend to use XInput mode anyway, cause it also supports force feedback.

Here is the default OpenTomb key mapping:

W / S / A / D — Forward / back / left / right.
SPACE — Jump / crawl jump
CTRL — Action (grab the ledges) / shoot
F — Draw weapon (select it via 1-7 hotkeys first!)
SHIFT — Walk / swan dive
CAPS LOCK — Sprint (if CAPS is on, Lara will always sprint)
V — Crouch
Z — Reset animation state (to get out of bugged states)
N — Noclip mode

PRINT SCREEN — Take screenshot
F5 — Quicksave
F6 — Quickload

Console command reference

Currently, OpenTomb has no menus, HUD or graphical UI, and only uses console for command input. To invoke console, press ~ key.

Here is the brief list of console commands to use:
  • setgamef ([game number]) — launch certain Tomb Raider game version. For example, setgame (2) loads Tomb Raider 2, and setgame (3.5) loads Tomb Raider 3: Lost Artifact.
  • setlevel ([level number]) — when game version is set, you can jumb between levels with this command.
  • help — show full console command help.
  • map "[level path and filename]" — forcibly loads specified level file.
  • save "[filename]" — saves game with specified filename in "save" subdirectory.
  • load "[filename]" — loads game with specified filename from "save" subdirectory.
  • freelook([0 or 1]) — switch free look mode on or off.
  • mlook([0 or 1]) — switch mouse look mode on or off.
  • cam_distance [value] — camera distance, 1024 by default.
  • playsound ([sound number]) — plays corresponding sound.
  • playstream ([soundtrack number]) — plays corresponding music track.
  • exit — quit game. You can also quit game by pressing Alt+F4 key combination (in Windows).

Screenshots & videos:


TeslaRus: main developer.
Cochrane: renderer rewrites and optimizing, Mac OS X support.
Gh0stBlade: renderer add-ons, shader port, gameflow implementation, state control fix-ups, camera programming.
Lwmte: state and scripting fix-ups, controls, GUI and audio modules, trigger and entity system rewrites, hair and ragdoll code.
Nickotte: interface programming, ring inventory implementation, camera fix-ups.
pmatulka: Linux port and testing.
Richard_trle: Github migration, Github repo maintenance, website design.
Saracen: room and static mesh lighting.
stltomb: general bugfixing and maintenance.
stohrendorf: CXX-fication, refactoring and general code optimizing.
T4Larson: general stability patches and bugfixing.
vobject: nightly builds, maintaining general compiler compatibility.
vvsgh: extensive testing, issue management on Github.

Additional contributions from: Ado Croft (extensive testing), E. Popov (TRN caustics shader port), godmodder (general help), jack9267 (vt loader optimization), meta2tr (testing and bugtracking), shabtronic (renderer fix-ups), Tonttu (console patch) and xythobuz (additional Mac compatibility patches).

Translations by: Joey79100 (French), Nickotte (Italian), Lwmte (Russian), SuiKaze Raider (Spanish).

Contribute to project

There were numerous attempts in TR engine reconstruction – OpenRaider, VT project, OpenTRX, TRPlayer, RetroFit... All of them were merely solo projects, and unfortunately, none of them reached final release or at least playable beta stage. Main point is, the more people work on a project, the more chances it will success.

So, if you love classic Tomb Raiders and can program in C++, it will be wonderful if you can contribute to OpenTomb development! Just post a request here or contact TeslaRus or Lwmte through private message and tell us what you can do!
Currently, ToDo list is pretty large: item interaction, graphic enhancements and menu system!

For those who want to contribute: we now have extensive tutorial on how to make OpenTomb integrate into Code::Blocks IDE.

Last edited by Lwmte; 31-07-15 at 14:15.
Lwmte is offline   Reply With Quote
Old 23-02-13, 21:55   #3
FairFriend's Avatar
Joined: Mar 2012
Posts: 228

This is one of the best thing that could happen to the tr modding community! the scope of the project is huge and the commitment of teslarus is truly remarkable. I hope that I will find time in the next months to dig deep into the code. Btw I'm glad you followed the advise and chose bullet
FairFriend is offline   Reply With Quote
Old 24-02-13, 08:19   #4
TeslaRus's Avatar
Joined: Jan 2013
Posts: 195
Default Bullet

This time I fully delete collide.cpp, trace.cpp. All physics works through bullet. I use dynamic rigid body (capsule with AngularFactor(btVector3(0.0, 0.0, 0.0)) ) as a character. Movement implemented with SetLinearVelocity function. To eliminate overlapping room collision I add btOverlapFilterCallback and check current room of the object (engine.cpp). But I have problems:
1) How to correct implement slopes?
2) Maybe bullet character controller is better than dynamic rigid body stick?

Last edited by TeslaRus; 28-02-13 at 13:43. Reason: I add filter to convex sweep test. One problem solved.
TeslaRus is offline   Reply With Quote
Old 10-03-13, 21:40   #5
Cochrane's Avatar
Joined: Apr 2006
Posts: 16,751

I just realized that I had completely forgotten about the Mac OS X port. Sorry about that. Anyway, I've now updated it to the latest version on Sourceforge:

As always, the source code is in my fork of the Sourceforge repository. There's some ugliness in the commit messages, but the code should all be valid:

For those feeling adventurous, but not up to using Xcode, here's a binary:

To use this:
  1. Download and extract the latest binary for Windows (from TeslaRus's Sourceforge page).
  2. All level files from any PC or Mac (OS X and OS 8/9) version of TR1-C will work, as should all TRLE files that do not use TREP or similar. If you have the Mac App Store version of Tomb Raider 2, you'll find them in the package contents in "Contents/Tomb Raider 2 Data/Data".
  3. Put the level files in the correct folder. You can edit the config files (instructions for this should be somewhere in the engine folder), just as you would on Windows.
  4. If you haven't yet, download and unpack the Mac version. This will give you the file
  5. Put this file in the engine folder (the same folder where engine.exe is).
  6. Start it. If you've edited the config files, you should be able to play right away, otherwise you'll have to use the map command, as Lwmte explained. Everything Lwmte said in the first two posts applies to the Mac version, too. One addition: To quit, you can use Command+Q.

This isn't yet the most elegant workflow. If you have any better suggestions how the app should work, I'd be glad to implement them. Especially if it makes the Mac version better than the Windows one.
Cochrane is offline   Reply With Quote
Old 11-03-13, 01:59   #6
trlestew's Avatar
Joined: Oct 2008
Posts: 13,177

I think this is a neat project that will really change how custom levels are designed in the future.
However, wouldn't the original TR games be left unplayable in this engine since the collision system is completely re-written?
trlestew is offline   Reply With Quote
Old 11-03-13, 08:16   #7
Cochrane's Avatar
Joined: Apr 2006
Posts: 16,751

I wouldn't worry too much about the original games. Their design is generally sane, with very few tricks used. There are not a lot of cases where the graphic geometry does not match the collision geometry; of the top of my head, I can only name water, cobwebs and the like, and the engine will have to support that anyway. You will be able to climb on any static mesh, and that will open up new exploits and shortcuts, and there are a lot of details that need to be handled properly, but I don't see those as big problems.

What I'm really interested in is how overlapping rooms and paperthin walls and the like will work. Those can be major challenges, because your typical physics engine is not prepared for them out of the box.
Cochrane is offline   Reply With Quote
Old 11-03-13, 14:15   #8
TeslaRus's Avatar
Joined: Jan 2013
Posts: 195
Default Character controller

Hi all! Bullet is very interesting physics engine. I found way to solve overlapping rooms problem and add RMB (right mouse button) test function to select objects (and switch animations by q - e buttons) or delete test spheres. But I did not make an alternate room filter.
In this time I make character controller (bullet's one does not approach to the Lara behavior). I use as a character dynamic rigid body (capsule shape) with angular factor 0. It allows to push items or be pushed by them. But using dynamic rigid body as a character prevents to ugly shake while mowing and I do not know how to realize slopes.
TeslaRus is offline   Reply With Quote
Old 15-03-13, 19:46   #9
Lwmte's Avatar
Joined: Aug 2010
Posts: 1,827

Originally Posted by Cochrane View Post
All level files from any PC or Mac (OS X and OS 8/9) version of TR1-C will work, as should all TRLE files that do not use TREP or similar.
It means you have fixed TRLE level loading? But I can't see any difference in TR4 level loader in your fork... Or the problem was somewhere else? I remember TeslaRus told about some zlib errors while unpacking TRLE levels.
Lwmte is offline   Reply With Quote
Old 17-03-13, 04:41   #10
TheBloodRed's Avatar
Joined: Dec 2009
Posts: 5,152

I'd love to see some video of some new effects in action. This is amazing especially because of cross-platform support!!
TheBloodRed is offline   Reply With Quote

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

All times are GMT. The time now is 20:13.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.
Tomb Raider Forums is not owned or operated by CDE Entertainment Ltd.
Lara Croft and Tomb Raider are trademarks of CDE Entertainment Ltd.