Robomodo RME

RME is the namespace Robomodo’s code uses for its engine: the executable names RME::Math::Vector4, RME::Gfx::FsFx::Silhouette and RME::Framework::Component, a subsystem called RME File I/O, and ships shader sources under rme\shaders\.... Observed · strings of the decrypted executable The name comes from those strings, not from the developer’s name. Inferred A retained continuous-integration path of the Demonware library carries the label rme-v2.0.0-ci; that is a workspace name, not a proven shipped engine version. Observed

The wiki records one game on it, Tony Hawk: SHRED (PlayStation 3, 2010). Nothing here is known about earlier or later Robomodo titles or about the engine’s lineage. Unknown

Content is stored in big-endian PAK archives, 336 of them on the disc, each a flat table of entries whose names are hashed with sdbm, many compressed in CSTR streams. An asset is often a set of entries that share a name and differ in extension: a level resource is a quartet (.scp, .mlp, .mmp, .mgp) and a texture a header and pixels (.thp, .txp), with the extension telling the loader which system reads it. Observed

Middleware

The executable carries these libraries; versions are given where the executable states one. Observed

Library	Version	How it is known	Confidence
Havok Physics	7.1.0-r1	version strings in the executable, and the same string in the header of a sample packfile	Observed
Scaleform GFx	3.0.74	version string next to gfxVersion	Observed
Lua	5.1	version string, and the chunk header of all 1,278 script files	Proven · all 1,278 script chunks
Wwise	not recovered	WWISE_ID in the executable; BKHD banks and AKPK packages on the disc	Observed
Bink	not recovered	Bink strings in the executable; 451 .bik videos on the disc	Observed
Morpheme	not recovered	a reference to morphemeSPU.elf, Robomodo animation task names, and five big-endian rig bundles on the disc (skinned streams)	Observed
Demonware	2.3.2	source paths retained in the executable	Observed
SQLite	3	27 database files on the disc	Observed

The executable also embeds a Havok physics identification string naming Robomodo and the title (...Physics.Robomodo_PS3-Xbox360_TonyHawk12) with the date 2011-10-29. The date is recorded as it is written; it is not shown to be the date of the build. Observed

What is known and what is not

Area	State	Confidence
Archives: PAK v4, CSTR, disc names	complete for the one disc	Proven · all 336 PAKs
Geometry: rigid meshes, vertex formats, placements, winding, skinned streams	every layout accounted for; tangent frames, tree extras and the skeleton pose not understood	Proven · all 657 quartets
Materials	records decoded; state words and the sampler order not understood	Proven · all 4,102 materials
Textures	all formats and volumes decoded	Proven · all 27,446 headers
Collision	triangles, shapes, bodies and surface ids; flag bits not understood	Proven · all 490 files
World: nodes, spots, splines, lights, layers	decoded; rails, light meaning and several section types open	Observed
Data model: MAIN.DB	all tables read; which the engine reads when is not traced	Proven · all 27 databases
Shaders: Cg containers, fragment microcode, texture-only programs, the fog pass	microcode decoded and checked against an independent disassembler; the material-to-texture-unit binding not traced	Proven · all 765 pixel program files
Animation, audio, scripts, UI	animation reference rigs read; the rest not covered	Unknown

The figures come from one PlayStation 3 disc, so a count that is proven is proven for that disc. Observed

What is RME’s own version, and where does it come from?

The only version-like labels in the executable are a Demonware workspace name and a Havok identification string with a date. Nothing ties either to a release of the engine.

Pages

Archives and files

• CSTR compressed streams — How a compressed PAK entry is stored: a CSTR header and blocks of raw deflate, each at most 65,531 bytes, stored uncompressed when deflate did not help.
• PAK archives — The big-endian PAK v4 container of the RME engine: header, 32-byte entries, section markers, sdbm name hashes, attributes and the alignment word.
• The disc and its file names — What a Tony Hawk: SHRED disc holds, how its files are named in the ISO 9660 primary tree and in the Joliet tree, and which of the two the game asks for.

Data model

• MAIN.DB and the other databases — The SQLite 3 databases of the game's database folder: the 142 tables of MAIN.DB (levels, sessions, goals, tasks, drop spots, surfaces, tricks, actors) and the tables other pages join on.

World and streaming

• Levels and layer PAKs — How a playable map is assembled: a base level PAK plus layer PAKs named by difficulty, session type and map id, what each layer holds, and the load order the level scripts give.
• Lights — The light records of the SCP blob: 80-byte records with a 64-byte matrix each, their colour, name, parameters and kind code, and what is not known about their meaning.
• SCP scene tables — The SCP file of a level quartet: its header, the node tree with world matrices, the joint table, and the chain of typed sections (spot chunks, splines, lights, cameras, occluders and others) after it.
• Splines — The polylines of the SCP blob: the five spline classes (probable grind rails, guide and camera ribbons, AI paths, the navigation layer's paths, short paths), the 56-byte record, the surface id, and how spline ids are named.
• Spot cameras, locators and occluders — Three small section types of the SCP blob: type 3 spot cameras (a spot name and two frames), type 5 locators (one waypoint) and type b occluders (a matrix and a line outline).
• Spot chunks and spawns — The typed volumes and points of a level (teleports, attractors, triggers, junctions and more): the 0x200-byte spot chunk, its class hash and shape, and how the database's drop spots name them.

Geometry

• Model libraries (MLP, MMP, MGP) — How a level's meshes are stored: an MLP resource table and metadata, an MMP buffer of positions and indices, an MGP buffer of the other vertex attributes, and the scene file beside them.
• Placements and matrices — How a level puts meshes in the world: the 48-byte placement records of an SCP, the 64-byte matrices they point at, instancing, and the mirror matrices.
• Skinned streams and skeletons — The processed skinning stream embedded in the metadata of character and crowd meshes: 64-byte batch headers with a four-bone palette, 64-byte source vertices, the skeleton in the SCP, and the Morpheme rigs that supply the binding matrices.
• Triangle winding — Which way the triangles of a SHRED mesh face: clockwise relative to the stored normals, over all rigid triangles of the disc, and how a reflecting matrix changes it.
• Vertex formats and UV selection — The mesh's vertex-format mask, the attribute order in the MMP and MGP streams, the packed CMP vectors and half-float UVs, and the four UV selector bytes of a submesh.

Materials

• Material banks (MBP and MDP) — How a submesh's material id becomes shader paths, parameters and texture paths: the three bank files, the MBP index, the MDP record, and which bank an id belongs to.

Shaders

• Shader programs — The compiled Cg programs of the SHADERS sections (.vsp, .psp, .shp), the RSX fragment and vertex microcode and how they decode, the programs that only scale a texture (sky domes, icons), and the full-screen fog pass with its level parameters.

Textures

• Textures (THP and TXP) — A texture is a header entry (THP, 84 bytes around a CellGcmTexture) and a pixel entry (TXP): formats, swizzle, mip chains, cube maps, volumes, and the prefetch and streamed copies.

Collision and physics

• Havok 7.1 collision packfiles — The Havok 7.1.0-r1 packfiles that hold a level's collision: the file structure and fixups, how triangle meshes, convex shapes and rigid bodies are stored, the per-triangle surface id, and the frame.